This page outlines the requirements that sponsorship has for a tool.

This document is a draft.


There are five parties who may be involved in sponsorship.

  • A contributor wanting to modify a package for which they do not have upload rights. (Sponsoree 1)
  • A contributor wanting to modify a package for which they do not have upload rights, but where they have a regular sponsor who reviews their work and uploads it for them (Sponsoree 2)
  • A contributor who cares about a particular package and has upload rights for it. (Sponsor 1)
  • A contributor who has upload rights to a portion of the archive, and has the time and inclination to help people get their contributions included in that area of the archive (Sponsor 2)


This section deals with the sponsorship requests.


Some of the people above would want to be notified at certain points:

  • Sponsor 1 wants to receive notifications whenever someone would like to get a modification to one of their pet packages uploaded.
  • Sponsor 2 may want to receive notification whenever someone would like to get a modification to one of the packages in their area of the archive uploaded. This should be something that they choose to have, rather than the default.
  • Both sponsorees want to receive notifications when there are changes made to, or comments on their requests.
  • There may be people outside of the above identified people that would like to receive notifications about certain requests.

Viewing outstanding work

People will also want to see the outstanding requests for certain cases:

  • Sponsorees 1 and 2, as well as tracking the progress of their own request, will want to see any outstanding requests for the package they are working on, as they may affect their work.
  • Sponsor 1 will want to list all outstanding requests against their pet package(s). They would probably like to be able to do this in one place, rather than one place per package.
  • Sponsor 2 will want to list the outstanding requests for their area of the archive, preferably in a way where they can sort/segment the requests by things like age, status of the request, etc.

Tracking request progress

Some of the parties will want to track the progress of a single request:

  • Sponsorees 1 and 2 will want to follow the progress of any of their own requests, and possibly follow others as well.
  • Sponsor 1 will most likely want to follow the progress of any request on their pet packages. However, they may not wish to follow requests that they are not active in (if someone else is sponsoring), but this is unlikely.
  • Sponsor 2 will probably only want to track the progress of requests in which they are participating. Some may want to track all, but they will presumably be few. There may be a case for reviewing a request and not tracking it if it is not ready yet, expecting that someone else will pick it up when it comes back around.

Preparing for sponsorship

This section is what a contributor needs to do to get sponsorship

  1. Prepare an updated package.
  2. Ask for sponsorship for the inclusion of that change in to Ubuntu. This will probably involve turning their change in to something which can be reviewed and used. This is what differentiates someone with upload access from someone without, this step would just be upload for the former.
  3. Respond to any comments from sponsors, potentially iteratively improving their change to the package. Eventually it will be uploaded or rejected.


  1. Take a sponsorship request, review the change within. If it is not ready then ask the sponsoree to improve it.
  2. Once it is ready take the change within and do whatever is necessary to make it ready for upload, and do so.


DistributedDevelopment/Requirements/Sponsorship (last edited 2009-04-02 09:33:15 by dholbach)