LicenseReviewProcessImprovementSpec
|
Size: 2986
Comment: removed irritating discrepancy between SpecSpec and SpecTemplate
|
Size: 2906
Comment: starting to reformat these
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = How to Write an Ubuntu Specification = This is an example Ubuntu specification, with comments on how to write a good Ubuntu specification. The better your spec, the better the chances that your ideas will be implemented in Ubuntu, and accepted by the distro team. == Status == |
|
| Line 14: | Line 6: |
| == Introduction == | == Summary == |
| Line 16: | Line 8: |
| This specification decribes the way we would like Ubuntu specifications to be written. It takes the form of a specification itself. You can see the SpecTemplate, which it is recommended you use for your own specifications in this system. |
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. |
| Line 31: | Line 27: |
| == Specification Structure == | == Use Cases == == Scope == == Design == |
| Line 62: | Line 62: |
== Implementation == == Outstanding Issues == == BoF agenda and discussion == |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/foo
Created: Date(2005-10-25T15:45:54Z) by MatthewEast
Contributors: MatthewEast
Packages affected:
Summary
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.
Rationale
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.
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
LicenseReviewProcessImprovementSpec (last edited 2010-10-26 13:56:51 by host194)