Add invoice for @JounQin

[JounQin]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)
• If applicable, I’ve added docs and tests

Description of changes

Hi, forks! I'm the core maintainer and developer of eslint-mdx, which is the ESLint Parser/Plugin for MDX.

I'm being developing this project since 2019-07-29, it was almost 3 years ago, time goes fast.

Some highlights of what I did these 3 years:

1. eslint-mdx@v1 parser support, eslint-plugin-mdx@v1 basic eslint plugin support

2. Integrate with remark-lint plugins, lint markdown syntaxes directly in ESLint

3. Integrate with eslint-plugin-markdown for linting code blocks in .mdx

4. Rewrite from scratch of eslint-mdx/eslint-plugin-mdx@v2 for mdx@v2

5. ESLint does not support native ESM and async parser/rules, I developed synckit for:

   Perform async work synchronously in Node.js using worker_threads with first-class TypeScript support.

6. In the period, I fixed several bugs and add some features in unified ecosystem like:

• feat(unist): add generic types for better type checking DefinitelyTyped/DefinitelyTyped#54413
• fix: support acornOptions.onComment and acornOptions.onToken micromark/micromark-extension-mdx-expression#4
• fix: always use DOMParser rehypejs/rehype-dom#19
• Add exports of defaultHandlers, all, one rehypejs/rehype-remark#9
• remark-stringify: fix types to disallow options.extensions remarkjs/remark#874
• Add exports of defaultHandlers, all, one remarkjs/remark-rehype#23
• Update unified-engine, hosted-git-info remarkjs/remark-validate-links#69
• Fix incorrect module field syntax-tree/hast-util-from-dom#13
• Fix type assertion syntax-tree/hast-util-is-element#3
• Add defaultHandlers export for reusing syntax-tree/hast-util-to-mdast#69
• Add support for base64url buffer encoding in types vfile/vfile#66
• https://github.com/JounQin/remark-preset-prettier

I'm trying to ask for invoice here because my house is being renovated, and I'm a bit out of funding balance, so I need some extra incomes, for my previous efforts on the projects, of course.

We have more things to do to improve mdx ecosystem:

• ci: add publish workflow for releasing on CI automatically mdx-js/mdx-analyzer#207
• [POC] Start support typescript mdx-js/mdx-analyzer#196
• Syntax Highlighting is broken for Fragments & components that start with valid Unicode characters mdx-js/mdx-analyzer#191
• [feat] IntelliSense support mdx-js/mdx-analyzer#165

[Murderlon]

Hi, thanks for the contributions. The unified budget generally has been tight as @wooorm has been living off it, but as far as I know he is for now in a more stable financial situation. With that in mind (and if he agrees to that), combined with the consistent contributions you presented, I think an invoice is okay here. Whether we can miss 5K on the other hand, is perhaps something up for debate.

[RichardLitt]

I'm curious - does unifiedjs have a larger process for deciding on how to communicate about how funds are spent?

[Murderlon]

Not at the moment but there is an issue for it (#34). Which makes processing this invoice (and future ones) mostly subjective and based on feelings on what is fair and what can be missed. Which isn't necessarily bad, but at least some clarity would help.

As there is no process, I would say we accept this invoice request unless someone from unified is against it with a good reason. From my perspective, after years of unified being on Open Collective, no one besides @wooorm has invoiced funds. So I'm good with not over-analyzing the work-vs-amount here, and go with the initial feeling — which is that this invoice seems fair and we can miss it.

If we suddenly get a lot more invoices, we can rethink and adjust.

[RichardLitt]

Thanks. I would be curious to help with that process.

Recusing myself as I work at Open Source Collective now, although my tenure with @unifiedjs is longer.

[wooorm]

Whether we can miss 5K on the other hand, is perhaps something up for debate.
— @Murderlon

I think this is the main thing for me.
Joun’s work on parts of unified is significant. But there are several people whose work (in the past) is significant. We can’t pay out everyone to the level they deserve.

Other than what we feel is fair, there is also the to backers and sponsors communicated primary goal of using funds for a full-time maintainer of unified.
(This is also why it wasn’t needed before to have an expense/invoice policy.)

---

@JounQin In your post, you divide things into what you did in the past, and in future work. My main thing with this invoice is that it is quite large.
Depending on whether you have time available the coming months, perhaps during the renovation, what if we’d split it up into two invoices. One for previous work now at a lower amount, and one in the future for something new?

In particular, I can see two projects that would be very useful for the community:

• That IntelliSense in vscode-mdx issue
• A lot of users want better syntax highlighting of MDX code in places such as GitHub. They are made with grammars such as this one. I could help a bit with this as I am very familiar with the MDX syntax, and also familiar with how these grammars work, and how to get them into GitHub.

Maybe you have other ideas? But first, I’d like to hear whether something like that makes sense, whether you’d have time, and what others think!

[JounQin]

My invoice here is only for my previous work, maybe you mean $5000 is too much for it? I don't know how to count it correctly and fairly because we don't have policy right? It was just my initial feeling. 😅

In the future, I want to work on some more features on vscode-mdx, it's the plan.

For me, without the renovation of my house, I won't be here for an invoice, my work on OSS are always by free, It's OK to me. But considering my family and current financial balance, I have to do it here. 😅

[wooorm]

maybe you mean $5000 is too much for it?

We have never before paid people for their past work.
We don’t have enough money to pay everyone for their past work.

It was just my initial feeling.

Do you need this amount of money for to the renovation, now, and quickly?
Would you need similar amounts in the future?

But considering my family and current financial balance, I have to do it here. 😅

I understand, and this is important for me: there are several people who deserve money, but don’t need it currently. You currently need money.

[JounQin]

Do you need this amount of money for to the renovation, now, and quickly?

Not in a very emergency for now.

Would you need similar amounts in the future?

I hope I don't need them always. But for the future, no can can guarantee. But I'll always ask according to my efforts.

[wooorm]

Thanks. Glad to hear this isn’t an immediate emergency!

What are your thoughts on my earlier comment, on splitting up this invoice in two separate invoices?

One invoice for previous work, which we don’t normally do, but because you need it.

One invoice for work while you are renovating or in the near future, that I imagine would benefit a lot of users, on a project such as I mentioned above.

I would find this easier to sign off on, because it’s a large sum, and we haven’t before paid people for past work (and we couldn’t pay everyone).

[JounQin]

What are your thoughts on my earlier comment, on splitting up this invoice in two separate invoices?

It seems the future plan is misleading.

This invoice is only for my previous work in 3 years, personally I thought the amount should be fair, but the bucket is tight, so you can give an advice how much should it count for my previous work. (After this invoice, it should be really a bit serious for us to add a related policy document).

[wooorm]

This invoice is only for my previous work in 3 years

In my experience with invoices, I first agree with someone about work to be done, then I do the work, and finally I send an invoice.
Part of my hesitation here is due to that: the invoice comes after the fact.

personally I thought the amount should be fair,

Yes, it is fair. However, other people also do work. It is also fair to pay them. But we can’t.

After this invoice, it should be really a bit serious for us to add a related policy document.

I would like to, but I would not know what to write in it. The goal is currently: get money to pay a full time maintainer of everything. We don’t have enough funds for that. If we’d have the funds, then we could dispense them, and write how to invoice for that.

---

It looks like no one is blocking this. Specifically, @Murderlon is fine with paying out the requested amount, and @RichardLitt has abstained.

I will also accept an invoice for the full amount you requested, after this discussion.

The reason that I will 👍 this, is, importantly, because you currently really need it. And I currently don‘t.

In the future, I will likely vote based on that too: whether we have the funds, and whether I am in a good financial situation to miss it or not.

---

Can you:

a) create a PR like this? The code is important. The PR does not need to be thorough, it can link to this issue.
b) Create another invoice to OpenCollective, with the agreed-upon amount?

Once you submit these two, I will agree, and other folks will have 72 hours to raise an objection. If there are objections, further discussion will take place. If there are no objections, I will accept your invoice.

[wooorm]

Also, importantly: our OpenCollective is in the United States. You will likely need to pay taxes on the money you invoice. I do not know anything about how taxes work in your case, so I can’t really advice on how to do it. But I wanted to mention it :)

[JounQin]

@wooorm

Thanks for accepting first.

I did follow #55 to create this PR: https://github.com/unifiedjs/collective/pull/56/files, can you give me advice what should I change to align in details?

[wooorm]

Oh sorry, I thought this was an issue! :)

/cc @unifiedjs/core Please review and approve this PR if you are OK with this PR/invoice at this amount. If not, please explain why!

[wooorm]

approved :)