launchpad helpWhat is Blueprint? Blueprint is the part of Launchpad that is concerned with tracking the development of new features in your software. It's where you can map out your roadmap, and prioritise the cool things you want to put into your next set of releases. It lets you build a community view of what's important, but it also lets individual contributors publish their own ideas and plans.
Blueprint tracks the metadata of "specifications". Each specification is a chunk of work, or a feature. It describes the work to be done, in whatever level of detail you think is appropriate. Each project has its own rules and preferred structure for these specifications, but the metadata is generally the same across all projects. So in general, these specifications are just simple wiki pages on a site that is relevant to the project (like the Ubuntu wiki, or the OpenOffice wiki). The specification might go into great detail about user interface changes, or code changes, or data model changes. Launchpad isn't concerned with that - it's concerned with whether the project thinks that feature is important, and who is supposed to be doing the work.
The metadata that Launchpad tracks covers the following areas:
Roles and responsibilities. Who conceived this idea? Who is responsible for saying when the idea has been specified clearly enough to get the go ahead? Who is authorised to say whether a particular feature is of high importance or no importance to the project team? Who gets to plan which features should be delivered in a particular release? Who is supposed to implement a particular feature? Who is currently drafting the specification?
Definition status. How well specified is this feature? Is it just a braindump - a short summary of an idea someone has had and does not want to forget about, or wants other people to think about, but which has not really received any kind of deep thinking or analysis? Is it currently being polished and drafted? Is it ready for a review by the project management team? Has it been approved - which means that the spec has enough information in it that everybody concerned reckons it's "defined" to the point where it's worth starting to hack on it?
Documentation. Often, you want to write up a "specification" that does not actually describe a chunk of work, but describes the current behaviour or desired behaviour of the system. We call those specifications "informational specs" and when they are "done" we publish them as documentation. This lets you maintain a dynamic list of the documents that describe your system, at a predictable URL.
Implementation status. Talk is cheap! So sooner or later people get down to tracking the actual coding and implementation process. Blueprint lets you keep the rest of the world up to date as to your implementation progress. If you have a deadline, you can tell the world if you are on target or falling behind. You can indicate that there is code available for review or for beta testing. When you are done, you can indicate that the code is ready for deployment - and when the sysadmins have got your bits into production or the code is committed to the repository then you can finally call it "Implemented".
Subscriptions. Lots of people might be interested in the progress of a particular feature, either when it is being planned or when it is being implemented. You can subscribe to any spec and then get email updates when its status changes. If the actual specification is being defined in a wiki, which supports email notifications, you can usually arrange for all the subscribers to the spec to get a note when someone changes the text of the specification too.
Obsolescence. Sometimes ideas go stale or are superseded. Launchpad lets you say "this was an idea we abandoned, or we instead decided to pursue this other course of action".
Dependencies and sequencing. You can break larger features down into smaller chunks, and keep track of the development of the constituent pieces independently. You can specify the dependencies of those chunks so that you always know what needs to be done next in order to reach your overall project goals. So Launchpad can always give you a roadmap for your project, and similarly, it can give you a roadmap for the work of an individual developer.
Related bugs. You can link specifications and bugs, so that people who file wishlist bugs know where to go to flesh out their ideas and turn them into reality. Of course, the links to the spec show up on all the bug pages, and the links to the bugs show up on the spec pages, so you can switch between the two very easily. Use Blueprint for the wishlist, future feature stuff. Use Malone for real honest-to-goodness bugs.
There's more in the pipeline too. Blueprint is a full-featured tracker that is heavily used by the Ubuntu team to manage complex releases twice a year. Without it, we wouldn't know where we stand from day to day. But it's not perfect, and so we're still looking for ideas and suggestions as to how we can make it better! Join us on #launchpad to talk further.
