BountyHub Proposal for NodeJs

[omarsoufiane]

This issue is a follow up of #1723 (bounty program) and is about a potential partnership between NodeJS and BountyHub.

Why should NodeJs consider a 3rd party platform instead of organizing a bounty program itself?

Bounties are not considered donations. Instead, bounties are payments for services rendered. A 3rd party platform like BountyHub would act as the middleman between the paying entity and the contributor so that NodeJs organization doesn't risk its non-profit status.
Managing payments, handling disputes, issuing tax forms (like 1099s for US contributors), and dealing with global compliance is a huge load. BountyHub specializes in that, letting the Node.js team stay focused on community and project growth.

How can NodeJs have governance over its bounty program?

One of the biggest problems regarding bounties created by the community is feature requests that are not wanted by the core team. Thus, NodeJs should have the ability to accept, reject, and shape the technical requirements of a bounty proposal before it is published.
NodeJs should have the final word regarding the acceptance criteria of pull requests.

Workflow of a bounty

Currently, BountyHub supports two types of workflows: either paying a bounty in advance, where funds are held in BountyHub's Stripe balance as escrow. or only paying after work is finished, which qualifies a bounty as "promised".
NodeJs would have the possibility to decide to limit bounty types on its repositories to only "paid in advance" which are subject to disputes* after a pull request is merged.
Bounties paid in advance can be retracted by the bounty creator if no pull request has been made.

Disputes

Disputes created involve a chat between the bounty creator, the bounty hunter (contributor), and BountyHub's team.
Unmerged pull requests are not subject to disputes because NodeJS has the final decision regarding the acceptance criteria of pull requests.
Disputes would primarily arise from disagreements between parties over whether the work is complete, as a merged pull request might not fully satisfy the original GitHub issue description defined by the bounty creator.
BountyHub pledges to guarantee fairness between all parties.

We are currently working on making BountyHub more organization-centric, and your feedback would help us shape its future. Let me know if you have additional requests or suggestions in case you decide to move forward .

[ljharb]

I'm not sure a project hosted by a nonprofit foundation can legally accept payment for services rendered.

[omarsoufiane]

@ljharb as discussed in #1723 funds will go to individual contributors not to openjs foundation

[ljharb]

ah gotcha, i missed that sentence in the OP :-)

[jasnell]

I'm still very much -1 on any form of this proposal at the moment as I believe it puts entirely the wrong kinds of incentives in place.

[mhdawson]

The TSC discussed this in the meeting today and of the TSC members in attendence (11) none of us advocated for the objection to be overruled and we agreed we should close out the issue as not something the project should do. Please let us know if you think that was not the right thing to do.

[omarsoufiane]

@mhdawson Thank you for reviewing my proposal and discussing it during your meeting. I watched the stream, and from what I gathered, most members prefer not to have Node.js officially associated with any bounty program, such as linking to one from the README. However, it seems there were no objections to individuals placing bounties on Node.js issues independently, outside of the project’s governance. That’s completely fine with me. My intent with the proposal was to help avoid potential problems, like what occurred in the Zig community, where bounties were placed on features that didn’t align with community priorities. I’ll continue to be available and would appreciate it if you reached out should any concerns arise regarding our platform.
Thanks again