Difference between revisions of "Bounty Program"

From GnuCash
Jump to: navigation, search
(note the open questions)
(use {{BugURL}})
 
(56 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
This page collects ideas for a potential bounty program within GnuCash.
+
This page describes the GnuCash Bounty Program "GCBoP" that was run and finished in summer 2013. Some review of the results can be read here [https://lists.gnucash.org/pipermail/gnucash-devel/2013-August/035954.html]. The rest of the page contains the program description from the time when it was run.
  
−
The idea is to announce bounties on specific commonly requested features. The bounties will be on the order of $100 or $200.
+
== Goals ==
 +
The goal of the GnuCash Bounty Program "GCBoP" is to make good use of some of our available donation money, specifically for the following aspects:
 +
* Get some issues fixed that have been a pain for many users but somehow were not interesting enough for developers previously
 +
* Attract new contributors by rewarding them for working on those issues
 +
* Stimulate current contributors to take on issues that remain open for too long
 +
* Experiment with this sort of bounty program in an Open Source project
  
−
== Features to be eligible for bounties ==
+
== Summary ==
−
The requested features or annoying bugs can be selected from those feedback sites:
+
The GCBoP program puts a bounty on the completion of any of the tasks that are listed as '''[[Bounty Program#Eligible Tasks|Eligible Tasks]]''' below, for any contributions received between June 1 and July 26, 2013.
−
* 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 act as '''Evaluators'''. As soon as some contributor sends in a patch that completes a task, one evaluator from our '''[[Bounty Program#Pool of Evaluators|Pool of Evaluators]]''' will 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 ==
+
See '''[[Bounty Program#How does it work?|How does it work?]]''' below for the full explanation of the program.
−
Other people have thought about running a bounty program in their software project as well:
 
−
* http://stackoverflow.com/questions/1276672/what-bounty-sites-do-other-open-source-projects-use
 
−
* http://live.gnome.org/BountiesDiscussion
 
  
−
== External bounty web sites ==
+
== Eligible Tasks ==
−
The following websites offer some sort of bounty management for specific feature requests.
+
=== Bugzilla ===
 +
The following items from [[Bugzilla]] are tasks whose completion will be rewarded by a '''$200 bounty''' (or '''160 EUR'''):
 +
* <strike>[{{BugURL}}/show_bug.cgi?id=514492 514492] Win32: Crash when loading data file with invalid txn dates </strike>
 +
* <strike>[{{BugURL}}/show_bug.cgi?id=669964 669964] Importing log file from a transaction that moves money between mutual funds creates a brokentransaction </strike>
 +
* <strike>[{{BugURL}}/show_bug.cgi?id=672595 672595] If the data file is not saved when the new file wizard terminates, no confirmation is issued if you exit gnucash </strike>
 +
* <strike>[{{BugURL}}/show_bug.cgi?id=678103 678103] Crash when creating new invoice </strike>
 +
* <strike>[{{BugURL}}/show_bug.cgi?id=691587 691587] Crash while loading corrupted .gnucash/stylesheet-2.0 </strike>
 +
Criterion for choosing those tasks: They have severity CRITICAL and remained opened for quite some time already.
  
−
http://nextsprocket.com/
+
Watch out: Your contribution must be prepared for the development branch. Even though some of the bugreports are for the 2.4 branch, you must make sure to prepare your bugfix so that it can be applied to the development branch.
−
* 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
+
=== Uservoice ===
−
* 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.
+
Also, the following items from http://gnucash.uservoice.com/ are tasks whose completion will be rewarded by a '''$200 bounty''' (or '''160 EUR'''):
 +
* [http://gnucash.uservoice.com/suggestions/1543027 Transaction Classifications] ([{{BugURL}}/show_bug.cgi?id=113772 Bug 113772])
 +
* [http://gnucash.uservoice.com/suggestions/1542903 Add Undo Functionality] ([{{BugURL}}/show_bug.cgi?id=509267 Bug 509267])
 +
* [http://gnucash.uservoice.com/suggestions/2047887 Make it easier for users to work with alternative/non-ISO/private currencies.] ([{{BugURL}}/show_bug.cgi?id=657215 Bug 657215])
 +
* [http://gnucash.uservoice.com/suggestions/1535933 Add the ability to attached scanned images to invoices.] ([{{BugURL}}/show_bug.cgi?id=336843 Bug 336843])
 +
* [http://gnucash.uservoice.com/suggestions/1589607 Type ahead search when entering the accounts to a transaction] ([{{BugURL}}/show_bug.cgi?id=545160 Bug 545160])
 +
* [http://gnucash.uservoice.com/suggestions/1539341 More charting: Budget vs. Actual chart] ([{{BugURL}}/show_bug.cgi?id=700801 Bug 700801])
 +
* [http://gnucash.uservoice.com/suggestions/1562955 Better Budgeting] ([{{BugURL}}/show_bug.cgi?id=700802 Bug 700802])
 +
* [http://gnucash.uservoice.com/suggestions/1547269 Allow the database to be secured by way of a password] ([{{BugURL}}/show_bug.cgi?id=700803 Bug 700803])
 +
* <strike>[http://gnucash.uservoice.com/suggestions/1602507 Manually change ordering of Transactions] ([{{BugURL}}/show_bug.cgi?id=700804 Bug 700804])</strike>
 +
* <strike>[http://gnucash.uservoice.com/suggestions/1539353 Allow saving of Custom Reports without changing name, overwriting existing report] ([{{BugURL}}/show_bug.cgi?id=649284 Bug 649284])</strike>
  
−
http://www.fossfactory.org/
+
Criterion for choosing those tasks: Those are the Top Ten feature requests by count of the user's votes. (Excluding the "declined" ones due to the immense structural changes they require.) And yes, they are not easy to do. That's the whole point of the GCBoP program.
−
* 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.
+
 
 +
'''Note''': Some of these projects may require significant changes to the Gnucash core. In those cases more is required than simply implementing the feature: You will also be required to ensure that any functions you touch are thoroughly unit tested before you make your changes and that those unit tests pass afterwards. You must also propose your design on the [mailto:gnucash-devel@gnucash.org gnucash-devel mailing list] for general discussion and approval before you begin coding. Failure to do so risks your patch being rejected because it is at odds with Gnucash's design principles rather than that it doesn't work.
 +
 
 +
Each suggestion has a corresponding bug report. These are in the suggestion item and also here for convenience. Once you have begun coding you will use the bug report to submit patches for review ''even if you have commit privilege''. You should also use the bug report to interact with the evaluator and any other interested developers or users.
 +
 
 +
== Pool of Evaluators ==
 +
The following developers are available as evaluators to decide whether a task is done:
 +
* John Ralls <jralls@ceridwen.us>
 +
* Christian Stimming <christian@cstimming.de>
 +
* Geert Janssens <geert@kobaltwit.be>
 +
* Derek Atkins <warlord@mit.edu>
 +
 
 +
== How does it work? ==
 +
==== Start Working ====
 +
If you want to work on any of the eligible tasks, you can start right away by checking the information provided in the bugzilla item or uservoice item.
 +
 
 +
As soon as you start working on any of the tasks, we strongly encourage you to add a short comment in the respective bugzilla item so that others are notified about your ongoing work and upcoming contribution. This is the best you can do to avoid unnecessary competition.
 +
 
 +
Please make sure to work on the development branch! Programmers new to Gnucash may find [[Contributing to GnuCash]] helpful, as might be the [http://svn.gnucash.org/docs/head/index.html Design and API Documentation] and [[C API]].
 +
 
 +
If you have technical questions on the GnuCash code base, do not hesitate to ask on the [[Mailing Lists#Development|gnucash-devel Mailing List]]. But please keep in mind: This is not a mentoring situation. Patch submitters are expected to have sufficient skill in C or Scheme  to accomplish the task with only code and design review as feedback. If the evaluators had time to teach you how to fix the bug, they would have done it themselves already.
 +
 
 +
==== Submit Contribution ====
 +
As soon as you have a code patch ready, attach it as an '''attachment''' of type '''patch''' to the indicated Bugzilla item. The Uservoice tasks all contain pointers to their corresponding Bugzilla items where the patches should be attached.
 +
 
 +
As the GCBoP program runs for a limited time, only patches that arrive between June 1 and July 26, 2013 are considered for a bounty. This is a hard dead line: If the final patch to complete the task does not arrive before July 26, 2013 (midnight EST), the work will not be considered for a bounty payment. Be sure to get your patch submitted early enough so that if further work is required there's time to submit corrections.
 +
 
 +
==== Evaluation ====
 +
One of the people from the pool of evaluators will review the patch within 48 hours. Be sure to notice if the attachment gets marked as "Needs Work": That means that you need to work on it some more and submit a new patch (don't forget to select the old one in the "obsoletes" list). Respond to any questions quickly. The *final* patch must be submitted '''before''' the deadline in order for you to get the bounty.  Either the evaluator or original poster must have confirmed that it fixes the bug or fully implements the requested feature, and the evaluator must agree that it is an acceptable solution acceptably written, ready to commit, and causes no regressions. The confirmation and acceptance may take place after the deadline so long as the patch submitted before the deadline is satisfactory.
 +
 
 +
If there isn't feedback on your contribution within 48 hours, please mention it on the [[Mailing Lists#Development|gnucash-devel Mailing List]].
 +
 
 +
==== Evaluator Decision ====
 +
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.
 +
 
 +
==== Disagreement Resolution ====
 +
Here's how we resolve a potential disagreement: 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.
 +
 
 +
Only patches that arrive before July 26, 2013 are considered for a bounty. The evaluation process itself may take longer than the deadline, but the patch for the final completion must have arrived before.

Latest revision as of 00:21, 30 June 2018

This page describes the GnuCash Bounty Program "GCBoP" that was run and finished in summer 2013. Some review of the results can be read here [1]. The rest of the page contains the program description from the time when it was run.

Goals

The goal of the GnuCash Bounty Program "GCBoP" is to make good use of some of our available donation money, specifically for the following aspects:

  • Get some issues fixed that have been a pain for many users but somehow were not interesting enough for developers previously
  • Attract new contributors by rewarding them for working on those issues
  • Stimulate current contributors to take on issues that remain open for too long
  • Experiment with this sort of bounty program in an Open Source project

Summary

The GCBoP program puts a bounty on the completion of any of the tasks that are listed as Eligible Tasks below, for any contributions received between June 1 and July 26, 2013.

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

See How does it work? below for the full explanation of the program.

Eligible Tasks

Bugzilla

The following items from Bugzilla are tasks whose completion will be rewarded by a $200 bounty (or 160 EUR):

  • 514492 Win32: Crash when loading data file with invalid txn dates
  • 669964 Importing log file from a transaction that moves money between mutual funds creates a brokentransaction
  • 672595 If the data file is not saved when the new file wizard terminates, no confirmation is issued if you exit gnucash
  • 678103 Crash when creating new invoice
  • 691587 Crash while loading corrupted .gnucash/stylesheet-2.0

Criterion for choosing those tasks: They have severity CRITICAL and remained opened for quite some time already.

Watch out: Your contribution must be prepared for the development branch. Even though some of the bugreports are for the 2.4 branch, you must make sure to prepare your bugfix so that it can be applied to the development branch.

Uservoice

Also, the following items from http://gnucash.uservoice.com/ are tasks whose completion will be rewarded by a $200 bounty (or 160 EUR):

Criterion for choosing those tasks: Those are the Top Ten feature requests by count of the user's votes. (Excluding the "declined" ones due to the immense structural changes they require.) And yes, they are not easy to do. That's the whole point of the GCBoP program.

Note: Some of these projects may require significant changes to the Gnucash core. In those cases more is required than simply implementing the feature: You will also be required to ensure that any functions you touch are thoroughly unit tested before you make your changes and that those unit tests pass afterwards. You must also propose your design on the gnucash-devel mailing list for general discussion and approval before you begin coding. Failure to do so risks your patch being rejected because it is at odds with Gnucash's design principles rather than that it doesn't work.

Each suggestion has a corresponding bug report. These are in the suggestion item and also here for convenience. Once you have begun coding you will use the bug report to submit patches for review even if you have commit privilege. You should also use the bug report to interact with the evaluator and any other interested developers or users.

Pool of Evaluators

The following developers are available as evaluators to decide whether a task is done:

  • John Ralls <jralls@ceridwen.us>
  • Christian Stimming <christian@cstimming.de>
  • Geert Janssens <geert@kobaltwit.be>
  • Derek Atkins <warlord@mit.edu>

How does it work?

Start Working

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

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

Please make sure to work on the development branch! Programmers new to Gnucash may find Contributing to GnuCash helpful, as might be the Design and API Documentation and C API.

If you have technical questions on the GnuCash code base, do not hesitate to ask on the gnucash-devel Mailing List. But please keep in mind: This is not a mentoring situation. Patch submitters are expected to have sufficient skill in C or Scheme to accomplish the task with only code and design review as feedback. If the evaluators had time to teach you how to fix the bug, they would have done it themselves already.

Submit Contribution

As soon as you have a code patch ready, attach it as an attachment of type patch to the indicated Bugzilla item. The Uservoice tasks all contain pointers to their corresponding Bugzilla items where the patches should be attached.

As the GCBoP program runs for a limited time, only patches that arrive between June 1 and July 26, 2013 are considered for a bounty. This is a hard dead line: If the final patch to complete the task does not arrive before July 26, 2013 (midnight EST), the work will not be considered for a bounty payment. Be sure to get your patch submitted early enough so that if further work is required there's time to submit corrections.

Evaluation

One of the people from the pool of evaluators will review the patch within 48 hours. Be sure to notice if the attachment gets marked as "Needs Work": That means that you need to work on it some more and submit a new patch (don't forget to select the old one in the "obsoletes" list). Respond to any questions quickly. The *final* patch must be submitted before the deadline in order for you to get the bounty. Either the evaluator or original poster must have confirmed that it fixes the bug or fully implements the requested feature, and the evaluator must agree that it is an acceptable solution acceptably written, ready to commit, and causes no regressions. The confirmation and acceptance may take place after the deadline so long as the patch submitted before the deadline is satisfactory.

If there isn't feedback on your contribution within 48 hours, please mention it on the gnucash-devel Mailing List.

Evaluator Decision

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.

Disagreement Resolution

Here's how we resolve a potential disagreement: 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.

Only patches that arrive before July 26, 2013 are considered for a bounty. The evaluation process itself may take longer than the deadline, but the patch for the final completion must have arrived before.

Retrieved from "https://lists.gnucash.org/wiki/index.php?title=Bounty_Program&oldid=14205"