BountyStrategy

Bounty Strategy

Status

Introduction

This will expand on the Bounty Strategy which is intended to be implemented. The idea for this BOF/Spec was to focus on the future strategy and direction of the Ubuntu Bounties, and establishing the Bounty Systems and Processes. Focus was not given to Bounty Topics at this stage.

Rationale

The reason for not focusing on Bounty Topics now, is that Bounties will come up all the time on an on-going basis, it is therefore important to ensure that there are effective and efficient processes available to deal with the Ubuntu Bounties. To take them from suggestion stage, through to deliverable completion and payment of the bounty. By ensuring that there are clearly defined and implemented processes and procedures, exceptional cases will be limited, and conflicts reduced. This in turn will reduce the admin and mediation overhead on bounties, which is currently an issue.

Once effective and efficient processes and procedures are implemented, the bounty lists can be drafted, and managed going forward.

Scope and Use Cases

This discussion focused primarilly on Ubuntu Related Bounties, however it is possible that Bounties for any track will be included in the Bounty Strategy.

Implementation Plan

Notes

Bounties are small, generally non-critical projects/pieces of development, or bug fixes etc which are offered to the community for completion in return for a monetary reward. Bounties may be tied to a release cycle, but they can not be critical for the release, as it is not guaranteed that bounties will be completed either on time, or succesfully for a release. If something is required or wanted for a release, and has been offered as a bounty it would need to have a completion deadline, with time left over to allow a distro team memebr to pick it up and complete in time for the release.

Larger Bounties can sometimes be handled as short term contracts, if a more formal relationship is required from either side. However this is not the prefered approach and generally the bounty system works on good faith and no formal contract will be entered into.

Bounties are only paid on completion, once delivered and accepted, and provided that this is within the required and agreed deadline.

The Bounties currently on offer can be seen at: ubuntulinux.org/community/bounties

Current Problems: Up to now Matt and/or JaneSilber have had to track and manage the Bounties. Matt has not had enough time to focus on Bounties, and currently they require a large amount of Admin, and Management. JaneW is to pick up the Admin and PM work on this, and Matt will only need to get involved in the more technical aspects. Bounties are not very widely or visibly advertised to the community - more focus should be given to this.

Conflicts

  • Issues arise if there is a race for the same Bounty (more than one person working on the same bounty at the same time).
  • Or a person has a bounty allocated to them and misses the deadline, or is not able to achieve the bounty requirement (even with a significant amount of work), in which case the bounty will not be paid out.

Rules must be clear and comprehensive to limit the oppportunites for conflict.

Bounty Tracker: MarkShuttleworth has been working on a Bounty Tracker system in Launchpad. Once completed this will be tested and then implemented. More detail on features and functionality is required on this. JaneW to ask sabdfl about having access to the system to test and eveluate for functionality etc.

  • It is possible to subscribe to Bounties, to track progress and see who the bounty is assigned to.
  • Currently does not track how the work is going - may need to cater for this over time.
  • Still under development not yet publicly released. Currently available on the launchpad dogfood server.

In future the Ubuntu wiki page should link through to the Bounty Tracker page on Launchpad

  • There may be a possibility to embed the Bounty Tracker functionality with Ubuntu specific search criteria into the Ubuntu wiki page.

Information Required for Bounties:

  • Ubuntu Bounty e-mail address -administrated by JaneW?
  • Name of person assigned to bounty
  • Contact details of person assigned to bounty- minimum of e-mail address
  • Description of Bounty/problem
  • Spec Template filled out by Bounty applicant with brief but clear details on how they intend to deal with the bounty.
  • Name of Reviewer (person responsible for approving and accepting completed bounty)
  • Contact details of reviewer- minimum of e-mail address
  • Time estimated to complete bounty (man days to complete piece of work)
  • Deadline (Date by when bounty is required to be completed)
  • Priority
  • Difficulty / Size of Bounty
  • Locked Bounty Expiry Date - if a person has been allocated a bounty with a lock-down, this is the date that they have exclusive rights on this bounty, before the bounty becomes open to all again.
  • Status bounties.
  • Progress Statement.
  • Put Checkpoints/Milestones into the deadline, define and schedule these up front.
  • Status of assigned bounties.
  • Put Checkpoints/Milestones into the deadline, define and schedule these up front.

Exclusivity? Need to see who is working on what? and show to community. How long do bounties stay locked onto specific name before being handed over?

Need spec requirements. Spec Template? Breezy Bounty's Bounties that are release specific.

Bounty Tracker - Must have PDF for each with Bounty showing terms and details. Time Specific rules must be upfront and clear. Can ask applicants for code discolsure, a time after bounty is booked, look at code and see what it looks like.

Questions:

  • Will Bountu Tracker be used to manage all aspects of Bounties?
  • When will the Bounty Tracker be finished, tested and ready for use?
  • Should we implement an MS Project Scheduling appraoch to track and manage and report on Bounty status and progress?
  • Are Launchpad Bounties included from the start?
  • Are external Bounties to be included in our system? - funded by other people and companies? Such as the Gnome Bounties. These will only be tracked here, but not managed by Canonical.
  • What is the current Bounty budget? What is the term of this budget? Who gets to allocate that budget?
  • When more than one person applies for bounty, how can you compare the proposals and rate them ito quality ?
  • Possibility of classing Bounties based on difficulty rating and/or size.
  • How long do bounties stay locked onto specific name before being handed over?

Data Preservation and Migration

Packages Affected

User Interface Requirements

Outstanding Issues

UDU BOF Agenda

The idea for this BOF was to talk about the future strategy and direction of the Bounties. To establish the Bounty Systems and Processes, and not to focus too much on Bounty Topics.

UDU Pre-Work

No pre-work was done.

Notes:

1. Need to be able to associate bounties to distros and products (need UI) 2. Need to be able to claim a bounty (user) 3. Deadline for Bounties 4. Need to be able to 'lock-down'/reserve a bounty - must have a deadline associated. Once this expires Bounty becomes open again. 5. Need to be able to track status of bounty, and progress and milestones. 6. Acceptance criteria 7. Reviewer - to accept/approve Bounty 8. Need spec template for proposals as well as for offered bounties 9. Difficulty rating 10. Measure of time estimate required to complete - man days 11. Man days actually taken to complete. 12. Payment method and process

CategoryUdu CategorySpec

UbuntuDownUnder/BOFs/BountyStrategy (last edited 2008-08-06 17:01:16 by localhost)