Difference between revisions of "Bounty Program"
(→Submit Contribution: Separate Evaluation, clafify time limit, add note about not mentoring.) |
(Move "Notification" up to "Start Working". Move the "no mentoring" note to "Add an editorial note about some of the UserVoice items.) |
||
| Line 46: | Line 46: | ||
Watch out: Some of the Uservoice tasks might require major structural changes in the gnucash code base. If you decide to work on this task, make sure to discuss your proposed structural changes early (!!!) enough on the gnucash-devel mailing list. Only this way you can ensure to have your solution accepted later. Otherwise you risk to have your contribution refused if it doesn't meet the majority of the GnuCash developers' ideas about the development of the GnuCash code structure! | Watch out: Some of the Uservoice tasks might require major structural changes in the gnucash code base. If you decide to work on this task, make sure to discuss your proposed structural changes early (!!!) enough on the gnucash-devel mailing list. Only this way you can ensure to have your solution accepted later. Otherwise you risk to have your contribution refused if it doesn't meet the majority of the GnuCash developers' ideas about the development of the GnuCash code structure! | ||
| + | |||
| + | '''Editorial Note: There's no way to complete a task involving major structural changes in a month's time, and some of these requests are contrary to Gnucash's design policies. I've already removed multiuser access for the former reason -- that's several years work, not a couple of weeks. We've not password-protected the database as a matter of policy, not because it's hard to do. Same with the thinly-disguised Bitcoin request. Accounting for Inventory can be done now: Just create a commodity for each item. The request is for an ERP system, and that Gnucash isn't and shouldn't be. --JR''' | ||
== Pool of Evaluators == | == Pool of Evaluators == | ||
| Line 59: | Line 61: | ||
''*DRAFT*'' 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. | ''*DRAFT*'' 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 bug report so that others are notified about your ongoing work and upcoming contribution. This is the best you can do to avoid unnecessary competition. | |
| − | If you have technical questions on the GnuCash code base, do not hesitate to ask on the | + | Please make sure to work on the [[SVN]] "trunk" branch! Programmers new to Gnucash may find [[Development]] helpful, as might the [http://svn.gnucash.org/docs/head/index.html Design and API Documentation] |
| + | |||
| + | If you have technical questions on the GnuCash code base, do not hesitate to ask on the [[Mailing Lists#Development|gnucash-devel Mailing List]]. | ||
| + | '''N.B.: 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 ==== | ==== Submit Contribution ==== | ||
| − | ''*DRAFT*'' As soon as you have a code patch ready, attach it as a '''patch''' to the indicated Bug report. '''Editorial Note: Surely some of the UserVoice items already have Feature Requests on them. For those that don't we should write one and in each case include to the on the list above so that there's no question which bug gets the patches for each item. We should add the evaluators to the CC list (or add a phony email that all of the evaluators can "follow") so that the evaluators get bugmail whenever there's a change on one of the bugs. Alternatively, each evaluator can adopt a couple of bugs and add himself as a CC on it.''' | + | ''*DRAFT*'' As soon as you have a code patch ready, attach it as a '''patch''' to the indicated Bug report. |
| + | |||
| + | '''Editorial Note: Surely some of the UserVoice items already have Feature Requests on them. For those that don't we should write one and in each case include to the on the list above so that there's no question which bug gets the patches for each item. We should add the evaluators to the CC list (or add a phony email that all of the evaluators can "follow") so that the evaluators get bugmail whenever there's a change on one of the bugs. Alternatively, each evaluator can adopt a couple of bugs and add himself as a CC on it. --JR''' | ||
As the GCBoP program runs for a limited time, only patches that arrive between May xx and June xx 2013 are considered for a bounty. This is a hard dead line: If the final patch to complete the task does not arrive before June xx 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. | As the GCBoP program runs for a limited time, only patches that arrive between May xx and June xx 2013 are considered for a bounty. This is a hard dead line: If the final patch to complete the task does not arrive before June xx 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. | ||
| Line 72: | Line 79: | ||
One of the people from the pool of evaluators will review the patch within 48 hours. Be sure to notice if it's marked "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, and the evaluator must agree that it is an acceptable solution acceptably written and ready to commit. The confirmation and acceptance may take place after the deadline so long as the patch submitted before the deadline is satisfactory. | One of the people from the pool of evaluators will review the patch within 48 hours. Be sure to notice if it's marked "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, and the evaluator must agree that it is an acceptable solution acceptably written and ready to commit. 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]]. | |
| − | |||
| − | |||
| − | If there isn't feedback on your contribution within 48 hours, | ||
==== Evaluator Decision ==== | ==== Evaluator Decision ==== | ||
| Line 86: | Line 90: | ||
Only patches that arrive before June xx 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. | Only patches that arrive before June xx 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. | ||
| − | |||
| − | |||
| − | |||
Revision as of 01:18, 6 May 2013
This page collects ideas for a potential bounty program within GnuCash.
Contents
Goals
*DRAFT* 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
Summary
*DRAFT* 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 May xx and June xx 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
DRAFT The following items from Bugzilla are tasks whose completion will be rewarded by a $xx bounty:
- 413494 Enable closing normally the application with kill -TERM
- 514492 Win32: Crash when loading data file with invalid txn dates
- 626970 Crash when saving a transaction whose destination account was deleted in the meantime
- 651981 Crash on restarting GnuCash after renaming accounts/modifying account hierarchy while a report is open
- 669964 Importing log file from a transaction that moves money between mutual funds creates a brokentransaction
- 670264 GnuCash won't open on User Account of Installer
- 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
- 679126 "You must select an item from the list" when an item has been selected from the list
- 691587 Crash while loading corrupted .gnucash/stylesheet-2.0
- 697950 could not input in the "open" dialog when using postgres or mysql database in Chinese on Win32.
Criterion for choosing those tasks: They have severity CRITICAL and remained opened for quite some time already. FIXME: Please remove items if they are again in NEEDINFO mode!
Watch out: Your contribution must be prepared for the SVN "trunk" 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 "trunk" branch.
Uservoice
DRAFT Also, the following items from http://gnucash.uservoice.com/ are tasks whose completion will be rewarded by a $xx bounty:
- Transaction Classifications
- Add Undo Functionality
- Make it easier for users to work with alternative/non-ISO/private currencies.
- Inventory system (mini inventory)
- Add the ability to attached scanned images to invoices.
- More charting: Budget vs. Actual chart
- Type ahead search when entering the accounts to a transaction
- Better Budgeting
- Allow the database to be secured by way of a password
Criterion for choosing those tasks: Those are the Top Ten feature requests by count of the user's votes. And yes, they are not easy to do. That's the whole point of the GCBoP program.
Watch out: Some of the Uservoice tasks might require major structural changes in the gnucash code base. If you decide to work on this task, make sure to discuss your proposed structural changes early (!!!) enough on the gnucash-devel mailing list. Only this way you can ensure to have your solution accepted later. Otherwise you risk to have your contribution refused if it doesn't meet the majority of the GnuCash developers' ideas about the development of the GnuCash code structure!
Editorial Note: There's no way to complete a task involving major structural changes in a month's time, and some of these requests are contrary to Gnucash's design policies. I've already removed multiuser access for the former reason -- that's several years work, not a couple of weeks. We've not password-protected the database as a matter of policy, not because it's hard to do. Same with the thinly-disguised Bitcoin request. Accounting for Inventory can be done now: Just create a commodity for each item. The request is for an ERP system, and that Gnucash isn't and shouldn't be. --JR
Pool of Evaluators
*DRAFT* The following developers are available as evaluators to decide whether a task is done:
- John Ralls <jralls@ceridwen.us>
- b
- c
- d
- ...
How does it work?
Start Working
*DRAFT* 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 bug report 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 SVN "trunk" branch! Programmers new to Gnucash may find Development helpful, as might the Design and API Documentation
If you have technical questions on the GnuCash code base, do not hesitate to ask on the gnucash-devel Mailing List. N.B.: 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
*DRAFT* As soon as you have a code patch ready, attach it as a patch to the indicated Bug report.
Editorial Note: Surely some of the UserVoice items already have Feature Requests on them. For those that don't we should write one and in each case include to the on the list above so that there's no question which bug gets the patches for each item. We should add the evaluators to the CC list (or add a phony email that all of the evaluators can "follow") so that the evaluators get bugmail whenever there's a change on one of the bugs. Alternatively, each evaluator can adopt a couple of bugs and add himself as a CC on it. --JR
As the GCBoP program runs for a limited time, only patches that arrive between May xx and June xx 2013 are considered for a bounty. This is a hard dead line: If the final patch to complete the task does not arrive before June xx 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 it's marked "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, and the evaluator must agree that it is an acceptable solution acceptably written and ready to commit. 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
*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.
Disagreement Resolution
*DRAFT* 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 June xx 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.
