Difference between revisions of "Bounty Process"
Jump to navigation
Jump to search
(Created page with "This is a guide on how to manage a bounty program for Mudlet - where a bounty program an incentive program that rewards open-source developers (Mudlet developers or outside) f...") |
(Clarify scope) |
||
| Line 1: | Line 1: | ||
| − | This is a guide on how to manage a bounty program for Mudlet - where a bounty program an incentive program that rewards open-source developers (Mudlet developers or outside) for fixing issues on an open source project. Here are the steps to follow: | + | This is a guide for Mudlet developers on how to manage a bounty program for Mudlet - where a bounty program an incentive program that rewards open-source developers (Mudlet developers or outside) for fixing issues on an open source project. Here are the steps to follow: |
# Inquire with the core development team to gauge their interest in picking issues to include in the bounty program. | # Inquire with the core development team to gauge their interest in picking issues to include in the bounty program. | ||
| − | # Dev team members should pick out issues they would like to see in the bounty program and label them as being worth $20, $30, or $50 worth of work. This process can be done asynchronously and in a Github project. | + | # Dev team members should pick out issues they would like to see in the bounty program and label them as being worth $20, $30, or $50 worth of work. This process can be done asynchronously and in a Github project (kept private - having it public led to confusion). |
# Once the issues have been identified, the team should get together and rotate turns picking issues out in a synchronous manner. The team should do rounds of 50 issues, then 30, then 20 to ensure an even spread of issue complexity in the bounty program. | # Once the issues have been identified, the team should get together and rotate turns picking issues out in a synchronous manner. The team should do rounds of 50 issues, then 30, then 20 to ensure an even spread of issue complexity in the bounty program. | ||
# Once the issues have been selected, put the bounties up. | # Once the issues have been selected, put the bounties up. | ||
Revision as of 06:27, 18 March 2023
This is a guide for Mudlet developers on how to manage a bounty program for Mudlet - where a bounty program an incentive program that rewards open-source developers (Mudlet developers or outside) for fixing issues on an open source project. Here are the steps to follow:
- Inquire with the core development team to gauge their interest in picking issues to include in the bounty program.
- Dev team members should pick out issues they would like to see in the bounty program and label them as being worth $20, $30, or $50 worth of work. This process can be done asynchronously and in a Github project (kept private - having it public led to confusion).
- Once the issues have been identified, the team should get together and rotate turns picking issues out in a synchronous manner. The team should do rounds of 50 issues, then 30, then 20 to ensure an even spread of issue complexity in the bounty program.
- Once the issues have been selected, put the bounties up.
- Developers will come and solve issues. When the team feels comfortable with the developer's identity, they should pay them on the specified PayPal account of the bounty taker. If the team feels the need to verify the identity of the developer, they should ask them to post or edit an existing comment with a particular (but random each time) text.
- The team should take the time to solve an issue to a good level. They should try to give most feedback upfront so that developers do not feel they are being "led around."
- Once the pull request (PR) is merged, the team should pay out to the bounty taker immediately in PayPal.
2023 is the first year we're starting with a pilot bounty, so expect this process to be refined and improved as we go.