SpecProcess
Differences between revisions 2 and 13 (spanning 11 versions)
|
Size: 3027
Comment: changed...
|
← Revision 13 as of 2008-08-06 16:39:29 ⇥
Size: 46
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = SpecProcess = == Status == * Created: 2005-04-27 by TollefFogHeen * Priority: NeedsPriority * People: TollefFogHeenLead, ColinCharlesSecond, JaneWQueue * Contributors: TollefFogHeen * Interested: * Status: DraftSpecification, UbuntuSpecification * Branch: * Malone Bug: * Packages: * Depends: * Dependents: [[FullSearch(SpecProcess)]] * UduSessions: 0 == Introduction == From the time a specification is "born" until it is accepted and implemented, is currently a big and under-documented process. Every specification should go through the life cycle as described in this specification. == Rationale == As the Ubuntu community moves towards a more specification-based process, a specification for the process itself is needed so everybody knows what the process should work like. The current process is fragmented and people seem to be confused with regards to what the proper process is. This causes excessive overhead and may cause specifications to be delayed unneededly. == Scope and Use Cases == The implementation of a spec is out of scope at this point. * A new idea is proposed and goes through the full process. == Implementation Plan == * A new specification is made, based on the SpecSpec template. * One or more BOFs are conducted. Discussion takes place. * The lead and/or second writes up the notes for the BOF. The BrainDump status is used at the Status field. * Once brain dumps become more coherent, the Status field should include "DraftSpec" and CommunitySpecification, DistroSpecification or LaunchPadSpecification. 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). They will review and edit the specification for clarity, spelling and grammar. * If the specification needs further clean-up's, 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. This could either be in the "comments" (this is limited to 80 characters), or kept within the document - this can be bolded, and placed in brackets. * 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 move the post-it note. * MattZimmerman or MarkShuttleworth then review the specification and move it to the ApprovedSpecification state by moving the post-it note and changing the state on the wiki. Otherwise, they send it back (?). * The specification is implemented. * When the specification is implemented, it reaches a state of ImplementedSpecification. === Data Preservation and Migration === N/A === Packages Affected === N/A === User Interface Requirements === Using the wiki. == Outstanding Issues == === UDU BOF Agenda === === UDU Pre-Work === |
See FeatureSpecifications and SpecLifeCycle. |
See FeatureSpecifications and SpecLifeCycle.
SpecProcess (last edited 2008-08-06 16:39:29 by localhost)