Ubuntu Wiki

This page describes the process by which we define, discuss, schedule and implement new feature specifications (also known as blueprints) in Ubuntu and Launchpad.

Ubuntu and Launchpad are both complex software projects with community involvement to various degrees. We need to keep track of many different initiatives, upstream and in the distribution, and we need to be able to know exactly where we stand on the delivery of those during the release cycle. We use the Launchpad Specification Tracker to do this.

Specifications are software design documents, and are best written by developers. If you are a developer, you are welcome to use this process. If you aren't, you may be better off using Brainstorm to gather support for your idea first, and persuade somebody with software design experience to take an interest in it. If your idea is reasonably small and confined to a single package or a small group of packages, then there's nothing wrong with filing a wishlist bug instead! Bugs are much more lightweight than specifications and often more appropriate; specifications are for large and complex tasks that need significant up-front discussion and design.

The Specification Process

1. Determine whether this process is appropriate. Are you proposing something large and complicated? If not, just file a wishlist bug on the appropriate package in Ubuntu. Is your idea reasonably well fleshed-out? If not, you might want to discuss it informally with a few other developers first.

2. Write your specification in the wiki. Take a look at the existing specifications to ensure that you are not duplicating an existing proposal. When you create the page, you are offered a list of Page Templates; use the one called SpecTemplate. The spec should be as detailed as you can make it: best practices documented are on the SpecSpec.

3. Register your specification in Launchpad. Specifications should be attached to either Ubuntu or a Launchpad product. Use the following quick URLs:

   1. https://blueprints.launchpad.net/ubuntu (Ubuntu, Xubuntu, Kubuntu and Edubuntu specs)

   2. https://blueprints.launchpad.net/rosetta (Launchpad Translations specs)

   3. https://blueprints.launchpad.net/malone (Launchpad Bugs specs)

   4. https://blueprints.launchpad.net/launchpad (General Launchpad specs)

   5. https://blueprints.launchpad.net/bzr (Bazaar specs)

   • The URLs above will list specs already registered. Use the "Register New Specification" link to add your spec. If you will be coding or implementing this yourself, make yourself the Assignee; otherwise, leave it blank. If you are the person responsible for drafting the specification and getting it to the point where it is approved, make yourself the Drafter. If there is someone else who will need to sign off on the spec before implementation begins, or will have to sign off on the code before it lands, then you should make them the Approver.

     An explanation of the specification data and approval process is at SpecLifeCycle. You should update the wiki page to include a URL for the Launchpad entry for the spec. This allows you to jump quickly between the wiki spec and its Launchpad entry. Do not set a priority for your own specifications; this will be determined by the project management teams. If this feature is very important to you, you can help by working on its implementation.

4. Propose the spec for discussion at a meeting. Launchpad keeps track of meetings held by the Launchpad and Ubuntu teams, e.g. UbuntuBelowZero, UbuntuDeveloperSummitMountainView, UDS-Sevilla. You can propose your spec for that meeting agenda using the "Add to Meeting" menu item (top right) on the spec page in Launchpad. Proposals are evaluated by the management team; if they can be adequately discussed at the meeting, they will be accepted. Please do not propose a spec for discussion at a meeting unless you, or somebody already willing to discuss the spec in detail, will be attending that meeting.

5. Gather a community around your specification. Don't assume that people will find it. Announce your spec on ubuntu-devel-discuss@lists.ubuntu.com and on #ubuntu-devel. Get people to subscribe to the spec as interested parties. If you have someone who wants to implement it, make them the assignee of the spec. NB, don't make someone the assignee unless they have agreed or you are funding them in some way. The better the community you can build around your idea, the greater the chances that it will be implemented soon, and well.

6. Work to get approval for the spec. When your spec is first registered it will be in the 'Brain dump' state. SpecLifeCycle describes the process through which the specification goes through before being approved.

7. Register spec dependencies. The specification tracker allows you to point to any other specifications on which your spec depends: if it only makes sense to implement B after A, you should say so in the Launchpad page for your spec. This is really useful when planning and prioritising the development team's efforts.

8. Start implementation of the feature. You should use Bazaar, publish your branches, and register them in Launchpad. In due course we will support linking of the branches directly to the specifications, so that people can find your code very easily.

Conclusions

Features that are proposed, caucused, discussed and implemented openly and transparently have the best chance of making it into Ubuntu and into Launchpad. Use this process to steer an idea that you have all the way to delivery. Bear in mind that you can't set priorities or goals for anybody else unless they agree to it, or unless they report to you, or you are willing to fund it. To make something happen, START it and try to gather people around you to make it go faster. Be willing to do it yourself, all the way, if necessary.

CategoryProcess