BountyIOTA (part II)
The full article was originally published by Ricard Royo on Medium. Read the full article here.
I am going to describe here an MVP of my proposed solution. Given the current development of Qubic we still can’t take advantage of smart contracts, oracles and quorum computations but we will use the current technology to our advantage in order to develop the best close approach. I also suggest taking advantage of GitHub API for our MVP but the goal is that our solution can integrate any other repository system/platform in the future.
Backer: Any person or organization that adds funds to a bounty.
Repository: Any open source repository published on GitHub, BitBucket, etc.
Issue: Any issue listed on an issue tracker from GitHub, Bugzilla, BitBucket, etc.
Bounty: A IOTA reward placed by one or many backers on an open issue.
Repository owner: The person that has control of commit permissions and manages the releases of the repository in GitHub, BitBucket, etc…
Bounty claimer: Any person that claims a bounty over a solved issue.
As a general concept I want the proposed solution to allow anyone to deposit IOTA into the system and offer a bounty to solve an open issue. Other backers should be allowed to contribute towards the bounty and increase the reward. Once the issue gets solved, the contributor can claim the bounty and the backers will get to decide whether the bounty should be sent to the bounty claimer or not.
Who should be allowed to create a bounty?
I believe anyone should be allowed to place a bounty over an open issue published in an issue tracker. I prefer to be as minimally restrictive as possible in this matter to incentivise the community getting involved in open source projects.
The only limitation should be placed in the restriction of having the issue published in an issue tracker. I enforce this restriction in order to have a clear definition of the requested tasks and to limit the scope to a specific issue and repository.
Permissions over who can publish issues on a certain repository will depend on the owner of the repository and should be out of the scope of the application. This doesn’t limit the capacity of proposing new functionalities in open source projects since there is always the option for the community to clone a repository and allow less restrictive permissions, ultimately creating community led repositories.
Who can claim a bounty?
Ideally the system should guarantee as much as possible that the bounty goes to the person that solved the issue. In the MVP I propose allowing for anyone to claim the bounty, but we could introduce security checkpoints in the future.
An example of such a security check point would be making sure the user has done a pull request in the repository or has been assigned the issue. The implications of such security checkpoints are out of the scope of this document and should be analyzed in detail.
Who should decide whether the bounty should be released?
I propose to place the responsibility of releasing the bounty on the the backers. Ideally, we would have them vote on (weighted to the deposited funds) whether or not a certain bounty should be released and paid to the claimer.