Difference between revisions of "Bounty Program"

From GnuCash
Jump to: navigation, search
(External bounty web sites)
(new draft)
Line 1: Line 1:
 
This page collects ideas for a potential bounty program within GnuCash.
 
This page collects ideas for a potential bounty program within GnuCash.
  
The idea is to announce bounties on specific commonly requested features. The bounties will be on the order of $100 or $200.
+
== Goals ==
 +
''*DRAFT*'' The goals of the GnuCash Bounty Program "GCBoP" are as follows: Use some of our donation money to
 +
* get long overdue issues fixed,
 +
* attempt to attract new contributors by rewarding them for working on those issues
 +
* stimulate current contributors to take on issues that remain open for too long
  
== Features to be eligible for bounties ==
+
== Summary ==
The requested features or annoying bugs can be selected from those feedback sites:
+
''*DRAFT*'' The GCBoP program puts a bounty on the completion of any of the tasks that are listed as "eligible tasks".
* http://gnucash.uservoice.com/
 
** Contains currently 90 ideas;
 
** The votes from the user give a clear ranking (similar to a scrum back-log), but the specifications are mostly rather vague and unclear.
 
* https://bugzilla.gnome.org/browse.cgi?product=GnuCash
 
** Contains currently approx. 600 bugs + 350 enhancement requests. Specifications for bugs are normally rather clear. Specs for enhancement requests vary; some are clear, some are not.
 
  
== Open questions before running a bounty program ==
+
Some of the current developers will be available as "evaluators". As soon as some contributor sends in a patch that completes a task, one evaluator from our "pool of evaluators" must, well, evaluate this contribution and decide whether a task is "done" so that the bounty is paid.
* Who decides on the general features that will be put a bounty on?
 
* Who decides on the per-feature bounty amount? This requires some estimation of the effort needed for the implementation of that feature, which means it will require development knowledge.
 
* Who is eligible to do work on a bounty?
 
* Is there some sort of "claiming" or "reservation" of a bounty in case a developer is actively working on it? How do we handle competing development offers on the same bounty, and who will make the relevant decisions in those cases?
 
* When is a feature "finished"? Who will make the final decision about whether a feature is finished and the bounty can be claimed? This decision ideally could involve somebody who was asking for this feature in the first place. How do we handle competing implementations?
 
  
== General set-up of a bounty program ==
+
== Pool of Evaluators ==
Other people have thought about running a bounty program in their software project as well:
+
''*DRAFT*'' The following developers are available as evaluators to decide whether a task is completed:
* http://stackoverflow.com/questions/1276672/what-bounty-sites-do-other-open-source-projects-use
+
* a
* http://live.gnome.org/BountiesDiscussion
+
* b
 +
* c
 +
* d
  
== External bounty web sites ==
+
== Process ==
The following websites offer some sort of bounty management for specific feature requests.
+
''*DRAFT*'' If you want to work on any of the tasks, you can start right away by checking the information provided in the bugzilla item or uservoice item.
  
http://nextsprocket.com/
+
''*DRAFT*'' As soon as you have your first and/or final code patch ready, file it in a bugzilla item. (If there isn't a bugzilla item available for a uservoice item, please create one.) One of the people from the pool of evaluators will respond to this item within 48 hours and give feedback whether the task is completed, or the task needs more work to be completed, or the evaluation takes slightly more time. If there isn't feedback on your contribution within 48 hours, feel free to ask on the gnucash-devel [[Mailing List]].
* The user interface is rather easy and straightforward. Multiple users can join their donation to increase the bounty on specific tasks.
 
* However, there doesn't seem support for management of multiple potentially competing offers.
 
* Also, there doesn't seem to be a status management such as "Is this bounty being worked on by any developer?" and so on.
 
* Payment seems to happen directly "from the task rewarder to the solution provider". 3% commission is charged.
 
* The site seems somewhat active. The site seems to be located in the U.S. (Irvine, CA).
 
* Unfortunately, the web forms seem rather buggy: When entering a new task in a Firefox 3.6, the entered details keep disappearing. Such as, the selected license keeps jumping back to "MIT" when I chose "GPL v2".
 
  
http://cofundos.org
+
''*DRAFT*'' Once the evaluator decides the task is completed, the payment can be sent and we will contact you about the details. If the evaluator decides the task is not yet completed, more work is needed from you.
* The site seems rather old and not very active (but there seems to be one recent task). It seems to have a rather sophisticated process for the management of task assignments: There is a structured requirement list; they can be commented on one by one. Multiple users can join their donation for specific tasks. A solution provider can tell his offer how much money he expects to implement the solution. The users can vote which offer to accept. Before a specific solution provider is chosen, there is a period of a "call for competitive offers" of three weeks (huh?). After that, a specific solution provider works on the implementation. All users will then vote whether the requirements are fulfilled. Votes are weighted by the donated money. The site is located in Germany.
 
  
http://www.fossfactory.org/
+
''*DRAFT*'' The fine print: If you disagree with the evaluation and think your contribution does complete the task, you may request evaluation from a second evaluator of our pool of evaluators. Please indicate so on the respective bugzilla entry. If the second evaluator confirms the non-completion of the task, this is our final response and no bounty will be paid unless the additional work is done. If the second evaluator comes to a different conclusion than the first one, a third evaluator will be asked to look on the task as well. After the third evaluator gave his vote, the majority of those three votes are our final response.
* The site seems rather recent, but still only with little activity. There is a structured requirement list. There does not seem to be support for voting which solution provider to choose. There does not seem to be a voting process to determine whether the task has been completed.
 
  
In German: http://www.heise.de/open/artikel/Die-Woche-Abstimmung-per-Geldbeutel-1478542.html summarizes various "Crowd funding" methods.
+
As soon as you start working on any of the tasks, we strongly encourage you to drop a short note in the respective bugzilla entry so that others are notified about your upcoming contribution. This is the best you can do to avoid unnecessary competition.
* http://www.kickstarter.com/ - rather for high-profile "single product" projects. In our case any crowd funding project would be about specific features of the existing software, so kickstarter is probably not very suitable.
+
 
* http://www.indiegogo.com - rather for arts or community projects
+
== Eligible Tasks ==

Revision as of 20:36, 5 May 2013

This page collects ideas for a potential bounty program within GnuCash.

Goals

*DRAFT* The goals of the GnuCash Bounty Program "GCBoP" are as follows: Use some of our donation money to

  • get long overdue issues fixed,
  • attempt to attract new contributors by rewarding them for working on those issues
  • stimulate current contributors to take on issues that remain open for too long

Summary

*DRAFT* The GCBoP program puts a bounty on the completion of any of the tasks that are listed as "eligible tasks".

Some of the current developers will be available as "evaluators". As soon as some contributor sends in a patch that completes a task, one evaluator from our "pool of evaluators" must, well, evaluate this contribution and decide whether a task is "done" so that the bounty is paid.

Pool of Evaluators

*DRAFT* The following developers are available as evaluators to decide whether a task is completed:

  • a
  • b
  • c
  • d

Process

*DRAFT* If you want to work on any of the tasks, you can start right away by checking the information provided in the bugzilla item or uservoice item.

*DRAFT* As soon as you have your first and/or final code patch ready, file it in a bugzilla item. (If there isn't a bugzilla item available for a uservoice item, please create one.) One of the people from the pool of evaluators will respond to this item within 48 hours and give feedback whether the task is completed, or the task needs more work to be completed, or the evaluation takes slightly more time. If there isn't feedback on your contribution within 48 hours, feel free to ask on the gnucash-devel Mailing List.

*DRAFT* Once the evaluator decides the task is completed, the payment can be sent and we will contact you about the details. If the evaluator decides the task is not yet completed, more work is needed from you.

*DRAFT* The fine print: If you disagree with the evaluation and think your contribution does complete the task, you may request evaluation from a second evaluator of our pool of evaluators. Please indicate so on the respective bugzilla entry. If the second evaluator confirms the non-completion of the task, this is our final response and no bounty will be paid unless the additional work is done. If the second evaluator comes to a different conclusion than the first one, a third evaluator will be asked to look on the task as well. After the third evaluator gave his vote, the majority of those three votes are our final response.

As soon as you start working on any of the tasks, we strongly encourage you to drop a short note in the respective bugzilla entry so that others are notified about your upcoming contribution. This is the best you can do to avoid unnecessary competition.

Eligible Tasks