Re: Re: Re: Tiki Bounty System
> 1- attach to current wishlist tracker (bounties as direct extension of wishlist)
This option is clearly my prefered choice 
I like the idea that everything is in one place, that you could offer a bounty for existing tracker items, etc.
I dislike the idea that option 2 would also imply to manage another website, that we may have duplicated items, that people will be a bit lost
> Possible problem 1: Some feature requests are very important from a code perspective, but not particularly attractive from a bounty perspective. The important stuff is left undone or delayed.
>
> Possible problem 2: Some feature requests are very important to the community (as reflected by the voting), but receive low bounty. Others are needed only by someone who happen to be rich (hence high bounty but low voting). This could get awkward.
I'm sure we can find a solution to minimize or revert problems 1 and 2. We juste have to decide what to do, but there is a lot of solutions. For example, supposing we manage bounties in dev.tw.o tracker5, we could :
- force the tracker to refuse bids from developpers for a bounty if there exists non-bounties tracker items that are more important
- add information "need a sponsor" on some very important trackers items (automatically or not), in order to incite sponsors to pay for some important stuff, since they don't see only bounties but also this stuff. I agree that sponsors tend to pay only for visible functionnalities, but some of them are also ready to pay for important things to be sure that the product will be healthy and have a long life.
- limit (by project admins ? by community votes ? by ) the list of developpers who can offer a bid / reply to a bounty to only those who often takes care of non-bounty items. There is also many solutions to manage this kind of short list : based on project admins decisions, based on firendship network, based on votes, based on the number of non-bounty tracker items already recently closed, ...
We can even choose to implement more than only one of this kind of idea.
Btw, if we suppose that we have a good system to affect priority to bugs that really reflects reality (through projects admins, main developpers, votes, ...), I then have a preference for the first example, since :
- It's completely effort-less (i.e. automated),
- It's not subjective,
- We clearly impose that money is not the most important thing,
- We may incite sponsors to help high priority bugs to be solved if they want their other less important developments to be done through the bounty system,
- This does not privilege some developpers
We may specify a more flexible rule. For example :
- no bid accepted for bounties if there is higher priority tracker items of priority > 8,
- no bid accepted for bounties if there is higher priority tracker items that includes bugs (not new features),
- no bid accepted for bounties if there is higher priority tracker items, except if the bounty has a high vote score,
...
> Possible problem 3: I think bugs should not be bountied. Even pledge of $20 to solve bug might cause crowding out of intrinsic motivation to fix bugs. This is my gut feel and also supported by economic theory that predicts crowding out. See http://www.slideshare.net/nice/crowding-effects-how-money-influences-open-source-projects-and-its-contributors/ By having all the bugs/feature requests and bounties together, the likelihood of crowding-out of intrinsic motivation could be very high.
Ok, I agree with you on tha fact that we should avoid bounties for bugs.
This has to be discussed (and marc to be convinced ;) ), but this is not so related to the choice of dev.tw.o. You won't be able to avoid bounties offer for bugs in another website. Even if you have no 'Bug' category, people will be able to describe a bug as a new feature request.
We can choose (if this is what we want), on dev.tw.o, to develop this system to be not usable / hidden for bug items.
;){kind=link}
;){kind=link}