Ubuntu Wiki

The Specification Tracker in Launchpad helps enforce a structured process for specification discussion, prioritisation and approval. This page defines the key data elements associated with a specification, and describes the process for BOF scheduling and spec approval.

Specification Basics

Each registered specification has the following data elements.

• Title: the person who registers the spec defines this. It will also be used in a URL.
• Summary: a brief description of the goal of the specification
• Product: specs will be attached to Ubuntu or a Launchpad product. Kubuntu, Xubuntu, and Edubuntu specs should be linked to Ubuntu.
• Priority: Initially this should be unassigned. The product manager(s) will assign a priority as one of
  • Essential: Features which must be implemented.
  • High: Features which are very important and will have resources dedicated to them.
  • Medium: Features which we hope to implement.
  • Low: Features which would likely be included in the system if completed, but which will only have resources assigned if available. Note that sometimes a spec may be low priority at this time, but increase in priority for a later release.
  • Not For Us: Specs in this category may still be a good idea, but are not appropriate for this product.
• Registered date: set automatically by the system

Roles

• Registrant: the person who registered the spec in Launchpad
• Assignee: the person responsible with primary implementation responsibility
• Drafter: the person responsible for completing the specification and getting it to Approved status
• Approver: the person with authority to give approval to a spec
• Subscribers: a set of people who are interested in the spec, would like to contribute to it, attend BOFs to discuss it

Workflow Elements

• Status: Initially this will be Braindump. The spec generally progress through the following states:
  • Braindump: an initial, rough description of the goal, issues, implementation plan
  • Drafting: a work in progress

  • Pending Review: ready for review by a member of the review team for readability and completeness. See SpecSpec for guidelines on how to pass review

  • Pending Approval: a reviewed spec which is ready for final approval
  • Approved: a golden spec
  • Obsolete: a spec which is no longer relevant
  • Superseded: a spec which is no longer relevant and has been replaced with a newer one
  • Informational: a spec which is simply documentation, not for implementation
• Meetings: a sprint or meeting at which the specification will be discussed. In order to get a spec discussed at the meeting, you must add it to the agenda. The meeting organisers will then review the submission mark the spec as:
  • Submitted: under consideration
  • Accepted: spec is appropriate for discussion at the meeting
  • Declined: spec is not appropriate for discussion at the meeting. Note that this is a not a reflection of the validity or priority of a spec. It may be declined simply because the people required for meaningful discussion are not attending the meeting, or because it isn't appropriate for the current development cycle.

• Blockers/Dependents: specs depend on each other. A specification blocks another if it must be implemented first. The spec to be implemented later depends on the first.

• Needs discussion: A flag to indicate that further discussion BOFs should be scheduled.

Approval Process

The following table reflects the typical approval workflow for a spec.

A team of people will be identified as reviewers for specs. Reviewers will read the spec for completeness and readability. They will ensure that only specs of sufficient maturity will be presented to the approver. The approver will read the spec for technical sanity, implementation details and give the final approval of the specification.

Schedule Process

1. Specs are registered. In order to have it considered by the schedule, it must be added to the meeting.
2. Meeting organisers will accept or decline the spec for the meeting. Normally a priority will be assigned at this time.
3. An automated scheduling system is used to create the BOF schedule. The scheduler takes into account
   • Key roles: it will require that the drafter and the assignee attend the session. It will try to get all subscribers to at least one discussion on the topic.
   • Drafting sessions: it will explicitly schedule time for writing up the discussion and decisions taken at the discussion session
   • Priorities: Essential and high priority specs will be scheduled first, followed by medium and low priorities. Sessions for other specs will not be scheduled
   • Available people: names of people who are not assigned in a given time slot will be used to identify lower priority specs which can be discussed
   • Pre-booked slots: sessions can be pre-defined and given to the scheduler as input. This is how to handle allhands sessions, or key meetings which need to take place but are not tied to a given spec. At each meeting the process for requesting one of these sessions will be announced.

4. The schedule will be re-run on a regular basis (e.g., nightly). If a topic needs further discussion, make sure that the Needs discussion flag is checked. If this is not checked, the scheduler will not consider this topic.

Implementation Process

The specs continue to be critical throughout the development cycle. The Spec Tracker includes functionality to link a spec to a particular release, or a particular milestone. These flags will be used by the project managers in scheduling work through the course of the development cycle.

CategoryProcess