Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Fixit district - bounty program for Github issues #177
Name: Fixit district
Building software is an iterative process of making small contributions to achieve a bigger goal. But currently there is no way to incentivise solving of particular smaller issues by the community or get rewarded for solving them as a contributor. I propose to create a widget for Github, implemented as a browser extension, that will allow
This is a very small project from the technical perspective, but it can provide important feedback channel between users and developers community.
@Bradymck Thanks for creating the new 'Bounty' label ;)
It's true, that #1 has the word 'bounty' in it too, but otherwise the proposals scope, focus and overall execution are entirely different. It is another web portal, where people need to sign up, learn the UI, visit regularly, create content, keep track of projects, actually read through descriptions - overall it requires a lot of effort from the user to get engaged and make use of it. That's a long story. It needs to create a lot of value in order to justify it's existence and win the user base from the other web portals.
Fixit, in contrast, doesn't need you to learn the new web portal and even be involved with the crypto community. You just need to have the extension installed, and you are able to reach the whole Github community - the world's largest developers community, established, active, with lots of content to monetise. Open source developers can finally get paid. Issues stalled for years can finally get resolved once they've got a price tag. Everybody instantly wins. That's the next big thing in the developer's world since Github, I'm telling you ;)
And all of these for 1 month of 1 developer's work or less.
This is a fantastic idea. I would be willing to personally fund some development if it were paid back after the bounty for new district0x districts was claimed.
What district0x infrastructure would it need?
Would the district be involved in resolving disputes?
How could the system be "gamed"?
@imdying Thanks for offering the funding!
Yes, it's not very clear how does it exactly relate to the District0x ecosystem and governance. For now it seems just using plain ETH w/o any other strings attached will be easier to implement for everybody to use.
To address gaming and disputes, I suggest the following scheme:
This way the system can't be gamed by developers (bounties can be cancelled anytime until the review period ends), and if it's gamed by the bounty givers, it will be visible by the developers, so they can make more educated decision on the actual probable outcome.
For example - say we have 3 bounty givers - each one gives 1 ETH bounty for the issue. 2 givers have 100% review rate (they've never cancelled their bounty during review), and one has 10% review rate (he is the "gamer", canceled his bounty during review 9 out of 10 times before). Then we show the bounty badge saying:
Total bounty is 3 ETH (estimated bounty is 2.1 ETH)
To address gaming and disputes, I suggest the following scheme: - After issue was closed, introduce a review period, during which developer can't claim the bounty, but community members are still able to cancel their bounty, if they are not satisfied with the result If the bounty staked was able to be locked (no withdrawls) by a dev for a small fee so that once the dev started working on it then the bounty couldn't be be pulled. If the bounty provider doesn't like the work then their stake, or a portion of their stake, is burnt, but also the devs stake. Both players have money in the game and the best outcome is for work to be done. The reputation of the devs and bounty providers could be tracked through a district 0x reputation module. This could be shared amongst all districts. - Keep track of bounties cancelled during review period for each bounty giver. And apply this ratio to display the estimated bounty amount to the developer for newly placed bounties, with the probability of cancellation factored in. Sounds good. This way the system can't be gamed by developers (bounties can be cancelled anytime until the review period ends), and if it's gamed by the bounty givers, it will be visible by the developers, so they can make more educated decision on the actual probable outcome. It could be gamed by the bounty givers though...