Ubuntu Wiki

At the beginning of every release cycle, we try to create a road map to document the work needed for the next cycle. The work is divided into what we call blueprints and each blueprint is then discussed at UDS. Below is an outline of how to create a blueprint.

Create a Blueprint in Launchpad

A listing of all Ubuntu blueprints can be seen at: https://blueprints.launchpad.net/ubuntu

To add a new blueprint just click on the Register a blueprint link. Then fill out each of the input fields keeping the following things in mind:

Drafting the Spec

The spec is a wiki page specification outlining the rationale, design, implementation, and testing that will be carried out for a blueprint. Each spec follows the same template. For the Ubuntu Kernel Team, we usually create all of our specs under http://wiki.ubuntu.com/KernelTeam/Specs/ , for example https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReview . At a minimum, create a placeholder for the spec based on the template and set the Specification URL when registering the blueprint. After discussion takes place at UDS, the drafter/assignee will be responsible to go back and fill in each section of the spec.

UDS

During UDS, a 1hr session will be scheduled for each blueprint during the week. If you are the assignee or drafter for a blueprint, you are required to attend this session. Be sure to takes notes during the session, especially for any decisions, design ideas, or work items which get discussed. Usually notes are taken in gobby (sudo apt-get install gobby) which is a collaborative text editor. These notes often help draft the final revision of a spec.

The UDS-P schedule for the entire week will eventually be posted at http://summit.ubuntu.com/uds-p/

Approved Specs/Blueprints

Once the spec/blueprint has been approved we can now begin addressing any work items that need to be completed. Each work item should be clearly documented in the whiteboard of the corresponding blueprint. A work item should represent a task that takes approximately 3-5 days work. If it requires longer, the work item should be broken up in multiple work items. Each work item should have a corresponding milestone which the work item is to be completed by. Each work item should also be assigned a specific owner (represented by your launchpad id), else it defaults to the assignee of the blueprint. Additionally, each work item needs to have it's status set to either "TODO", "INPROGRESS", "DONE", or "POSTPONED". An example whiteboard would look like the following:

Work items ubuntu-12.04-beta-1:
[apw] review set of upstream patches:DONE
[leannogasawara] publicise final kernel version after we hit kernel freeze:TODO
[leannogasawara] finalize kernel config changes:INPROGRESS

Work Items for ubuntu-12.04-beta-2:
[canonical-foundations] disable apport kerneloops:TODO

Work Items for ubuntu-12.04:
[leannogasawara] Final kernel content and configuration report to ubuntu-devel:TODO