Ubuntu Wiki

The Specification Tracker in Launchpad helps enforce a structured process for specification discussion, prioritisation and approval.

Specification Basics

Each registered specification has the following data elements.

• Name: the person who registers the spec defines this. It will also be used in a URL.
• Product: specs will be attached to Ubuntu or a Launchpad product
• Priority: Initially this should be unassigned. The product manager(s) will assign a priority as one of
  • Essential:
  • High:
  • Medium:
  • Low:
  • Not For Us:
• Status: Initially this will be Braindump. The spec generally progress through the following states
  • Braindump
  • Drafting
  • Pending Review
  • Pending Approval
  • Approved
  • Obsolete
  • Superseded
• Registrant:
• Assignee:
• Drafter:
• Approver:
• Registered date:
• One or more BOF (discussion group) sessions are conducted. Here discussion takes place to explore ideas and firm up a direction for the topic at hand.

• The lead and/or second writes up the notes for the BOF. The BrainDump status is used in the Status field, to indicate that the brainstorming/discussion phase is still in progress.

• Once the brain dump stage evolves into more coherent and complete ideas which have been documented in the spec, the Status field should be changed to DraftSpec. Also CommunitySpecification, DistroSpecification or LaunchPadSpecification should be added to the status field as appropriate to indicate which track the topic belongs to. It may also include "NewSpec" as a state. "ColinCharlesQueue or SimonSharwoodQueue" should be added to the list of People (yes, that's both of them). This will alert them to the fact that they are now required to review the spec. They will review and edit the specification for clarity, spelling and grammar. It is a good idea to physically go to them and talk through the spec content with them.

• If the specification needs further clean-ups, it will be sent back by the specification editors. This is done by adding "Queue" to the end of the name of the lead and the second along with comments on what changes are needed. Everyone should be checking their Activity pages. This could either be done in the "comments" section (this is limited to 80 characters), or kept within the document - this can be bolded, and placed in brackets, for easy visibility and identification.

• Once the lead and second are happy with the changes as they come back from the editors, the Editors change the state to EditedSpecification and the lead or second goes to the Global room to progress the post-it note to the appropriate section.

• Specifications which are ready to be submitted for approval should be placed in MattZimmerman or MarkShuttleworth's queues (by adding MattZimmermanQueue or MarkShuttleworthQueue to the people field). Matt / Mark will then will then review the specification and move it to the ApprovedSpecification state by moving the post-it note and changing the state on the wiki. It is a good idea to notify Matt or Mark in person of a spec is waiting on their approval, to avoid any unnessecary delays. Should the spec NOT be approved they will place it back in the queue of the person who sent it to them.

XXX

• state. Over time, its status will change from 'brain dump' to 'draft' to 'approved'. There are a variety of states there. Please do not move a spec to 'approved' unless it really has been approved by the people who have to land the code. You can mark it 'Draft' when it has everything in it that you think it should have, including implementation strategy and discussion of any UI, with mockups, and an assessment of its impact on existing code. When you are really, really certain its good, you can move it to 'Pending Approval'. The approver can bump it back to draft or braindump. Don't mess around with the status, people will just start to ignore your specification. Really.

has many features. It allows you to ask someone to review your spec, for example, and keeps track of that. It also