Blueprint keeps track of who's planning what, who's working on what, who's supposed to sign off on what, and who's supposed to review what. It also allows projects to exercise control over the planning and prioritisation of features so that the community can know exactly which piece is most likely to benefit from their support and contributions.

Specification Roles

Each specification keeps track of the following people:

• Assignee. Somewhat obviously, this is the person who has been tasked with or has tasked herself with the job of delivering the feature that is described in the specification.

• Drafter. The drafter is someone who is responsible for drawing up the detailed plan. More often than not this is the assignee, especially for a feature that is conceived and implemented by the same person. But in the case of larger projects you might well have people sharing the load of implementing and drafting, or use the drafting role to get new members of the project to demonstrate their insight and knowledge about project conventions and infrastructure by drafting specifications. In the Launchpad and Ubuntu spec sprints we often have people collaborating by drafting one another's specs - it helps to ensure that the more experienced developers can contribute to the discussions of a wider variety of features, while newer developers focus on learning the ropes in a particular field. Offering to draft a spec for a feature you are interested in is a great way to show the lead developers of a project that you know your stuff and are able to structure and present your ideas.

• Approver. If the code has a chief architect, or there is a customer, or there is someone who needs to have final say in the way a feature is implemented, then make them the approver of the specification. The spec will show up in a special report for that person, so they know when to look over it and give it any final tweaks before marking it Approved.

• Registrant. The registrant is the person who actually recorded the spec in Launchpad.

Project Drivers

Blueprint also keeps track of the people in the project who have the responsibility for setting priorities and release goals. We call these people the "drivers" since they determine the major direction and pace of feature development. The same group are responsible for determining the importance of specific bugs to a major release, they essentially say what needs to get done before a major new series or distribution release can be called "done".

Now, in Launchpad, a project (upstream or distribution) has a very specific structure. And you can specify drivers that have responsibility for the whole project or just for parts of it. This tree illustrates the basic structure of a typical upstream or distro project:

•    UPSTREAM
       Project (Optional)        "mozilla"
         Product                 "firefox"
           Product Series        "1.5"
  
     DISTRIBUTION
       Distribution              "ubuntu"
         Distro Release          "dapper"

Note that for upstreams, the "project" is optional. Launchpad keeps track of upstreams as products, which can be libraries or applications. If you want to group those together into projects, then thats great, but often products are "standalone".

Each of these parts of the project structure can have a driver associated with them. But specifications in Blueprint can only be targeted to a Product Series ("firefox 1.5") or a Distro Release ("dapper"). We'll explain what that means below. For the moment, the important thing is to know that when you are looking at the "firefox 1.5" series you might see that it has up to three drivers - one from the series, one from the product, and possibly even one from the project.

This allows a project to appoint someone who has "driver" responsibility in ANY series in ANY product in the overall project. For example, that person could be the most senior architect or development team, with the ability to determine the priorities of any library or app in the project. For example, in the case of the Mozilla project, that would mean that they could approve a bug for fixing or a feature for implementation in any major release of Firefox, Thunderbird, Gecko, Necko or Sunbird.

At a lower level, you might have a person or team who have "driver" responsibility for a single product - they could approve features for any series in that product, like 1.5 or 2.0. And of course, you can appoint a team or person to be the driver of a single series. Those people will only have permission to target a spec to that series, not to any other series in the project unless they are explicitly given that permission too.

So this allows upstreams to control who is in the drivers seat for any particular major line of development.

Similarly, for distributions, you can have an overall driver at the distribution level, and then separately you can add specific drivers for specific releases. Now, this is useful because drivers will also be able to approve a bug fix for backporting to an existing release. That means that might you want to have a larger team that is "driving" the NEXT release, and then a much smaller backporting team that is responsible for approving the backporting of fixes to bugs in older stable but still-supported releases.

In both upstreams and distributions, the "drivers" for a series or release is the set of drivers from the tree above that series or release. So for upstream, if you have set a driver on the series, the product, and the product is part of a project with a driver, then you would have three drivers who can approve specs for that series.

Unspecified Driver

You do not HAVE to specify a driver. In general, Launchpad will recognise the driver(s) you tell it is (are) responsible for a product, project or series. If NO drivers have been set, anywhere in the "tree", then it will use the registrant of the top-most object in the tree as the driver. In the case of distributions thats simple - its just the registrant of the distribution. In the case of an upstream series, though, it depends on whether or not the product is part of a project. If it is, then the project registrant becomes the driver for every series in the project. If there is no project then the product registrant is the driver for every series in the product.

This may sound complex, but it basically means that after you create a product and/or project, you can create series and start targeting specs to those series. You will automatically be the driver on all of the series in your product if you registered your product. The permissions will "just work". Nobody else will be able to approve specs to series unless you specifically empower them to do that, by making them a driver or making them part of a team that is a driver.