Thoughts about the Public Bounty program


#1

As shown in our newly created Developer Portal, in addition to the Responsible Disclosure bounty program, I also introduced a “Public Bounty Program” for the general development.

The basic idea is that we should have a place for people to engage in the project. I classify the engagement in a few parts:

  1. Submit a (non critical) bug or feature request
  2. Join the discussion
  3. Show the support to the idea
  4. Fix the bug / implement the feature

GitHub issue system can be used here. A user can submit a bug or feature request as a GitHub issue in the Developer Portal repository. Next, the community can join the discussion. When an issue gets enough support, the dev team or any community contributor can implement it and close the issue.

The system won’t work well without incentives. So here we can introduce a bounty for each GitHub issue. There can be two types of bounty: the one from BTG development fund, and the one from the community (totally optional). The dev team will assign an amount for the open issue if the team believes the task deserves it. But users can also show support by donating towards the work. When the task is finished and accepted by the community, the dev bounty as well as the communtiy donation will be paid to the contributor.

The bounty model is already adopted by BitShares (bitshares-ui repo). Taking them as a reference, I believe a good starting point for the bounty can be ranged from $50 to $1000 (not considering some rare cases). Beyond the defined bounty, the community can also donate to show the support or influence the priorities for development.

When the task is completed, all the funds will be paid to the contributor. In case there are multiple contributors, BTG team will decide how to split the bounty among the contributors. When the task expires (obsolete or impossible to complete), any donations will be returned to the donators.

Put it all together, here we get the full model:

  1. Submit: Anyone can submit a bug or a feature request to the Github issue system.
  2. Arrange: The BTG dev team arranges the issues (dedupe, deal with spam, tag, create bounty wallets, etc)
  3. Discuss: Anyone can discuss the issue
  4. Donate: The community can optionally donate to the issue
  5. Match: The BTG dev team will consider the properties of the task and define the dev bounty. It can be seen as “matching the donation”.
  6. Develop: Anyone can finish the task
  7. Pay: Excluding paid developers on the dev team, the contributor will get the dev bounty plus the community donation.
  8. Future donation: When the task receives additional donation after the bounty payment - “appreciation” - we will redirect the donation to the contributor directly.

#2

I think you should clarify this - I believe you mean the dev team will match the value of filling a request or fixing a bug to some dollar value for the assigned bounty. I suggest “Assignment” instead of “Match.”

“Matching the donation” is inherently confusing because of the (Western?) tradition of “Matching Donations” or “Matching Gifts” - this is where a company or a benefactor promise to make a donation equal to whatever amount is donated by the public.

image