SpecSpec
|
Size: 2906
Comment: starting to reformat these
|
Size: 2971
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| * '''See also''': SpecTemplate | |
| Line 8: | Line 9: |
This specification decribes the way we would like Ubuntu specifications to be written. It takes the form of a specification itself. The better your spec, the better the chances that your ideas will clearly understood by the review team. See also SpecTemplate, which is recommended as a template for your own specifications in this system. |
This specification describes the way we would like Ubuntu specifications to be written. It takes the form of a specification itself. |
| Line 18: | Line 13: |
| As we develop new ideas for features in Ubuntu it's important to have a clear idea of the exact status of each idea. Putting this content in the wiki gives our community a chance to participate in the discussion and design of a feature, and increases the chance that community members will feel confident enough to start work on the implementation of the feature. A good specification allows community members who were not physically present at meetings discussing a topic to participate in the implementation of the spec. |
As we develop new ideas for features in Ubuntu, it's important to be able to communicate them clearly. This serves the purpose of making it clear what the feature is about, and allowing people to evolve an implementation strategy for it. Putting this content in the wiki gives our community a chance to participate in the discussion and design of a feature, and increases the chance that community members will feel confident enough to start work on the implementation of the feature. A good specification also allows community members who were not physically present at meetings discussing a topic to participate in the implementation of the spec. Bottom line: the better your spec, the better the chances that your ideas will clearly understood by the review team. |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/foo
Created: Date(2005-10-25T15:45:54Z) by MatthewEast
Contributors: MatthewEast
Packages affected:
See also: SpecTemplate
Summary
This specification describes the way we would like Ubuntu specifications to be written. It takes the form of a specification itself.
Rationale
As we develop new ideas for features in Ubuntu, it's important to be able to communicate them clearly. This serves the purpose of making it clear what the feature is about, and allowing people to evolve an implementation strategy for it.
Putting this content in the wiki gives our community a chance to participate in the discussion and design of a feature, and increases the chance that community members will feel confident enough to start work on the implementation of the feature.
A good specification also allows community members who were not physically present at meetings discussing a topic to participate in the implementation of the spec.
Bottom line: the better your spec, the better the chances that your ideas will clearly understood by the review team.
Use Cases
Scope
Design
The spec is broken into a number of sections and sub-sections. We describe each of these in turn:
The title. A short heading for the spec, no more than 12 words.
The status metadata. This section contains some well-defined
- metadata for the spec. It's important to put in as may flags and tags as possible that accurately describe the state and scope of the specification. These flags are used to generate reporting pages automatically. Please use as many flags as make sense for this spec
from the following list: HighPriority, LowPriority, MediumPriority, UduBof, UbzSpecification, BrainDump, DraftSpecification, ApprovedSpecification, ImplementedSpecification, DistroSpecification, LaunchpadSpecification, CommunitySpecification, UbuntuTrack, KubuntuTrack, EdubuntuTrack, LaunchpadTrack.
- metadata for the spec. It's important to put in as may flags and tags as possible that accurately describe the state and scope of the specification. These flags are used to generate reporting pages automatically. Please use as many flags as make sense for this spec
Introduction. A brief introduction to the topic or spec. This
should not attempt to tell why the spec is being defined, just what is being specified.
Rationale: a summary of why this spec is being defined.
Scope and Use Cases. The use cases are not always required, but
- in many cases they bring much better clarity to the scope and scale of the specification than could be obtained by talking in abstract terms.
Implementation Plan. This section is usually broken down into
- subsections, such as the packages being affected, data and system migration where necessary, user interface requirements and pictures (photographs of drawings on paper work ell).
Implementation
Outstanding Issues
BoF agenda and discussion
SpecSpec (last edited 2010-05-30 17:13:07 by dsl-185-83-10)