SpecProcess

Differences between revisions 1 and 4 (spanning 3 versions)
⇤ ← Revision 1 as of 2005-04-27 03:12:30 →
Size: 2486
Editor: intern146
Comment: Initial submission for editing
← Revision 4 as of 2005-04-27 06:06:35 → ⇥
Size: 4650
Editor: intern146
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * People: ColinCharlesQueue  * People: TollefFogHeenLead, ColinCharlesSecond, ["ColinCharlesQueue"]
Line 9: Line 9:
 * Interested:
 * Status: BrainDump, UbuntuSpecification, NewSpec		  * Interested: ["JaneW"], MattZimmerman
 * Status: DraftSpecification, UbuntuSpecification
Line 21: Line 21:
From a spec is "born" until it is accepted and implemented is a big and underdocumented process. Every specification should go through the life cycle as described in this specification. The process from the time a specification is "born" until it is accepted and implemented, is currently a large, mostly undefined and under-documented set of procedures. Every specification should go through the life cycle as described in this specification.
Line 25: Line 25:
As the Ubuntu community move to 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. As the Ubuntu community moves towards a more specification-based process, a specification for the process itself is needed. This is so that everybody knows how the process should work. The current process is not yet mature, and is therefore still fragmented, for this reason it is confussing and is not being followed in a standardised way. This has caused extra overhead at the UDU conference and may cause specifications to be delayed unnecessarily.
Line 29: Line 29:
The implementation of a spec is out of scope at this point. The implementation of the specs is out of scope at this point, this will be tackled after the conference. For now the focus is on completing the specs and getting them approved and allocated for action.
Line 31: Line 31:
 * A new idea is proposed and goes through the full process. A new idea is proposed and goes through the full process.
 * The scope of this spec includes defining and documenting the proposed process (and/or procedures) for handling a specification from conception, through to approval stages.
Line 35: Line 36:
 * A new specification is made, based on the SpecSpec template. '''Process:'''
Line 37: Line 38:
 * One or more BOFs are conducted. Discussion takes place.  * A new specification document is created on the wiki, based on the SpecSpec template, when a spec is required.
Line 39: Line 40:
 * The lead and/or second writes up the notes for the BOF. At this point the Status field should include "DraftSpec" and CommunitySpecification, DistroSpecification or LaunchPadSpecification. ColinCharlesQueue or SimonSharwoodQueue should be added to the list of People. They will review and edit the specification for clarity, spelling and grammar.  * 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.
Line 41: Line 42:
    * If the specification needs further cleanup, it will be sent back by the 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.  * 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.
Line 43: Line 44:
 * Once the lead and second are happy with the changes as they come back from the editors, they change the state to EditedSpecification and go to the Global room and move the post-it note.  * 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.
Line 45: Line 48:
 * 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.  * 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.
 This could either be done in the "comments" sesction (this is limited to 80 characters), or kept within the document - this can be bolded, and placed in brackets, for easy visibility and identification.
Line 47: Line 51:
 * The specification is implemented.  * 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.

 * The specification is then queued for implementation. (Process to be defined for this later).

 * When the specification is implemented, it reaches a state of '''ImplementedSpecification'''.

SpecProcess

Status

Introduction

The process from the time a specification is "born" until it is accepted and implemented, is currently a large, mostly undefined and under-documented set of procedures. 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. This is so that everybody knows how the process should work. The current process is not yet mature, and is therefore still fragmented, for this reason it is confussing and is not being followed in a standardised way. This has caused extra overhead at the UDU conference and may cause specifications to be delayed unnecessarily.

Scope and Use Cases

The implementation of the specs is out of scope at this point, this will be tackled after the conference. For now the focus is on completing the specs and getting them approved and allocated for action.

A new idea is proposed and goes through the full process.

  • The scope of this spec includes defining and documenting the proposed process (and/or procedures) for handling a specification from conception, through to approval stages.

Implementation Plan

Process:

  • A new specification document is created on the wiki, based on the SpecSpec template, when a spec is required.

  • 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. This could either be done in the "comments" sesction (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.

  • The specification is then queued for implementation. (Process to be defined for this later).

  • 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

SpecProcess (last edited 2008-08-06 16:39:29 by localhost)