Revision as of 23:29, 17 February 2013

Launchpad blueprints are used to track the implementation of significant features in OpenStack. Keeping their status current is critical to the success of the release and the project as a whole. It avoids unnecessary reporting, pings and discussions, and keeps everyone on the same page.

Blueprints reference

Blueprints offer a forum for listing and planning specifications for work to be done. Whereas one could think of these as bugs with a "Feature Request" priority, there is actually a more fundamental difference. A bug is a description of a problem, and a blueprint is a description of a solution. It would be perfectly legitimate, given the scope of a particular problem, to file a bug on a problem and then to write up a blueprint describing the approach to solving the problem. For most bugs this would be a rather large waste of time, but is merely pointed out to underscore the difference in purpose.

The Blueprint system itself is quite simple, and the only thing required to create a blueprint is a title and a description of the blueprint. It is expected that longer-form official writeups of the approach would go on a wiki page, and accordingly the blueprint has a field for specifying where the writeup can be found. The intent here is that if you write a proper description of the work in the wiki, then once you are done with it you will be left with some form of documentation describing a particular feature.

Blueprints, like bugs, can be targeted towards different release series and different milestones, so that at any point it's simple to see what the status of intended work is.

Blueprints can also be used as the basis for planning in-person meetings. Launchpad contains a facility to register meetings, and blueprints can be targeted to available meetings as an element of agenda.

Adding a Blueprint

Adding a blueprint is simply a matter of going to the project's blueprints page, such as

https://blueprints.launchpad.net/nova

and clicking on "Register a Blueprint".

Assigning a Blueprint

Blueprints carry metadata about who wrote the spec, who approved the spec and who is implementing the spec. If there is a blueprint that you are going to be working on, simply change the assingee to yourself and off you go.

Updating Status

Blueprints carry a status field about the relative status of the work. Although not strictly necessary, updating this status removes the need to constantly answer questions from your manager of "what's the status on project X"

Available Fields in blueprints

Here are the different fields available in Launchpad blueprints, and how we use them within the OpenStack project.

Specification link

URL to an additional document, potentially describing the design and implementation details.

Priority

PTLs use priority to communicate how important a given feature is to the success of the next release.

Definition

PTLs may ask you to use the definition status during the planning phase of the ReleaseCycle.

Implementation

Use this status to indicate the degree of completion of your blueprint. This is mandatory.

Extra statuses:

Series goal

The release series (Essex, Folsom...) targeted by this blueprint. This is used by the PTL to build the roadmap for a given release.

Approver

The PTL for the project.

Drafter

The person responsible for the planning phase on this blueprint.

Assignee

The person responsible for implementing the blueprint. This is mandatory.

Milestone target

The milestone the blueprint should be completed by. This is mandatory.

Related branches

Not used.

Related bugs

Bugs related to this blueprint, if any.

Sprints

Not used.

Feedback requests

Not used.

Whiteboard

Free-form notes. If the blueprint implementation is blocked, this should state the reason why. Gerrit will add notes about corresponding reviews in this field.

Dependency tree

Dependencies between blueprints. If one blueprint needs to be delivered before this one, this needs to be recorded here.

Blueprints lifecycle

Creation

If you intend to work on a given feature, you should create a blueprint for that. Describe the feature summarily in the blueprint itself, and link to another document (using the specification link) if you have more.

Note that you may track the peer-review of your blueprint using the Drafter and Definition fields.

Once it is ready for PTL review, you should set;

• Approver: <the PTL for the project>
• Assignee: <who will do the work>
• Series goal: Proposed for <the current development series>
• Milestone: When you think your work will be proposed for merging

Inclusion in the release roadmap (PTLs)

The PTL reviews the blueprint, then may include it as a release goal:

• Definition: Approved
• Series goal: Accepted for <the current development series>
• Priority: <blueprint priority> (see above)

During development (assignee)

The "Implementation" field should reflect progress in your work:

• Implementation: <degree of completion> (see above)

Please update the implementation status regularly to avoid being pinged about it :)

When merged (assignee)

When the work is fully merged, finalize the spec by setting:

• Implementation: Implemented

See also

• ReleaseCycle
• Bugs