Blueprints: Lightweight Specifications

Planning isn't quite the least-favorite thing for most free software developers - but it's more or less in the same region as dealing with spam. The free software process is highly agile, with release management policies that span the full range from "time based" (set the date and forget the features) to "when it's done" (set the features and forget the date). Launchpad doesn't aim to change the psychology of projects by imposing any planning, but it does at least help a project to communicate to itself, and to other projects, where things stand.

The idea is simply to have a placeholder for each "chunk of work", or idea for implementation, or documentation that should be written. We call that placeholder a Blueprint. It can be as little as a single sentence, or a fully-fledged specification with data model and user interface mockups. The level of detail required is entirely a matter for the project to decide.

Each of these Blueprints belongs to a particular project. That means you can see lists of all the ideas or proposals or suggestions that are "out there" for a given project. For example, Ubuntu has more than 1,000 such blueprints, in various states of completion or discussion:

• https://blueprints.launchpad.net/ubuntu

At the time of writing, the most "important" of these blueprints were:

attachment:ubuntublueprints.png

You can see, for each blueprint, a priority, a "definition" status, and a "delivery" status.

The priority is set by project leaders. Anybody can contribute blueprints for any project - there is no way to prevent someone from posting their ideas. However, the project leaders can set the priority - which means the extent to which they endorse the idea, or think it is important to implement soon.

The "definition" status tells you whether or not the project has reached consensus on how the idea should be implemented. In some projects there will be a person, or team of people, who will approve the plan. In others, plans are considered unnecessary or harmful, so this value is less important. In Ubuntu, we try to have a senior contributor review and approve any significant piece of work that is planned for any given release. Of course, lots happens without these plans, but it does give us some certainty that the various plans gel well, and that people have thought about the most important issues before they commit to getting something done in a particular release.

Finally, the "delivery" status is all about implementation and execution. It tells you whether the work has been done, or whether it is on track to be done.

Launchpad itself only contains a summary of the blueprint - usually just the introductory paragraph - and then a URL to the location of the real document. In some cases the single paragraph (or sentence) is enough, but it's more typical to keep the full document in a wiki, where members of the community can collaborate on it easily.

Just having a list of proposals and ideas in one place is useful, even if, as in the case of Ubuntu, there are clearly many more ideas than developers! It's convenient to be able to point new members of the community at a single place where those ideas are cataloged, to allow people to gravitate towards the pieces they are most interested in. People can subscribe to blueprints and get notifications when their status changes (or even when the wiki document they are in is updated). And newcomers can easily see which ideas are important to the project leaders, and which are not, so if they want they can focus their contributions on those pieces most likely to be accepted into the project.

Linking blueprints

It's possible in Launchpad to link a blueprint and a bug, or a blueprint and a branch. In this way people can start to see how pieces of work are related to one another. It's very useful, for example, to be able to see the code that implements a blueprint evolving over time. It's also possible to link blueprints to one another - indicating rough dependencies. This lets you map out the order in which pieces should be implemented.

Release management

The most useful aspect of Launchpad's blueprint tracker, however, is the ability to group together the blueprints which describe chunks of work that the project thinks are important to track for the next major series.

Here is the list for the Feisty (7.04) release of Ubuntu:

• https://blueprints.launchpad.net/ubuntu/feisty

As you can see, this is a much shorter list (about 100 blueprints instead of 1100). These are blueprints that have been reviewed by the team, and the plan at the beginning of the Feisty development cycle was to get those features implemented. In general, about 80% of the planned feature goals have landed in each Ubuntu release - we choose to ship on time rather than necessarily waiting till every feature lands - but different projects can adopt different release management goals.

The important thing, of course, is that everyone can see where we stand on any particular item.

The blueprint capability in Launchpad is not designed to do hard-core project management. It doesn't do Gantt charts or waterfall diagrams or block out developers hour by hour. But it certainly can improve the communication within a project, and between projects, about the status of work that has been discussed. Organising blueprints by release helps to communicate a clear picture of where any give release stands - what's in, what might get in, and what's not going to make it.

The release management that we've described here is at the level of major releases - what we call a Series. Sometimes you want to group together just the blueprints that are relevant for an interim release. For that, we'll use milestones. And learning about those is the [:ReviewersGuide:MilestoneUsage:final stop on our tour].