Fixit district - bounty program for Github issues #177
Comments
|
This is similar to the proposal #1. Bounty.io is geared towards ICOs though I think a general purpose bounty system and a Chrome extension would be awesome. |
|
@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) |
|
@afanasy Check out CommitETH, seems similar in scope and intent |
|
@afanasy there is also Fundrequest.io to reward contributions to software. A browser extension for github and stackexchange are on the roadmap. |
|
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...
|
|
@Alexand0x @Gillepils Thanks for the references, both are interesting projects. @imdying Dev can game the system by locking bounty forever then, so locking may not work. I like burning-on-cancellation (high cancellation fee) idea, it will help to stop bounty "spam". |
|
Why would you need a browser extension? Couldn't you give github users the possibility to link their public address to get a bounty |
|
@Clearwood extension would serve as a link between Github and blockchain, with no party in the middle. Otherwise if you make a web page, it is centralised. |
|
Hey @afanasy , I'm not sure if you're aware but we recently launched a new bounty to migrate your proposals to the actual District Registry: https://registry.district0x.io/ We're replacing the old voting app with the registry. Let me know if you need help but I would love to see you migrate this over so you can claim your DNT. It does take a 10,000 DNT submit to submit your proposal but this gives you an extra 2000 you can stake in the registry beyond the deposit amount. Hit me up on Telegram or Discord if you need help or have questions. Telegram: https://t.me/district0x/75217 PS, please excuse the canned response. I am encouraging everyone here to start migrating so they can claim their 12000 DNT. |
Name: Fixit district
Purpose: Facilitate software development by focusing on smaller contributions
Description:
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.
And it can be immediately applied to the current District0x needs - facilitate the development of District Proposals, which are the Github issues already.
ETH: 0x71182691d210c40e7f85e12d4152f0be9b0ff70b
The text was updated successfully, but these errors were encountered: