FeatureDefinition
|
Size: 635
Comment:
|
Size: 1864
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| || '''Starts:''' || 1st week of development <<BR>> || || '''Ends:''' || 5th week of development <<BR>> || |
In the beginning of a development we do feature definition. |
| Line 7: | Line 6: |
| * discuss on the mail list and irc channels on feature additions * finalize blueprints at week 4, and have them approved |
== Tasks during feature definition == |
| Line 10: | Line 8: |
| == Feature Specifications (blueprints) == | ||<style="width: 15%"> week 1-8 || Discuss on mail list, irc and social channels about feature additions. Collect ideas - preferably directly to lp blueprint specifications. Call for developers to participate during this whole period. || || week 8-9 || finalize [[UbuntuStudio/Blueprints|blueprints]] at around week 4, and have them approved before FeatureDefinitionFreeze || == Making Feature Specifications (blueprints) == |
| Line 13: | Line 14: |
=== Suggesting changes === Anyone can suggest a feature change/addition. But, to make it a reality, someone needs to implement it. Usually the one who does the work is the same person that makes the suggestion. === Creating Blueprints === Blueprints are created for projects, and the blueprint should be created by the driver of that project (typically ubuntustudio-dev, or ubuntustudio-art), or the owner (typically ubuntustudio-core). === Approving Feature Specs === * If a feature spec is not objected, it will automatically be approved. * If a feature is objected by anyone, it needs to be discussed within the community. If no resolution is found, ubuntustudio-core team, whose responsibility lies in upholding the quality and integrity of Ubuntu Studio, has last say . * If a feature spec will break something in Ubuntu, it may be disapproved by the ubuntustudio-core team. Also, it will most probably be disapproved later by Ubuntu devs anyway. |
In the beginning of a development we do feature definition.
Tasks during feature definition
week 1-8 |
Discuss on mail list, irc and social channels about feature additions. Collect ideas - preferably directly to lp blueprint specifications. Call for developers to participate during this whole period. |
week 8-9 |
finalize blueprints at around week 4, and have them approved before FeatureDefinitionFreeze |
Making Feature Specifications (blueprints)
Planning of feature changes is done primarily by the use of feature specifications in the form of blueprints at http://launchpad.net. See our Blueprints page for an oversight of our active blueprints.
Suggesting changes
Anyone can suggest a feature change/addition. But, to make it a reality, someone needs to implement it. Usually the one who does the work is the same person that makes the suggestion.
Creating Blueprints
Blueprints are created for projects, and the blueprint should be created by the driver of that project (typically ubuntustudio-dev, or ubuntustudio-art), or the owner (typically ubuntustudio-core).
Approving Feature Specs
- If a feature spec is not objected, it will automatically be approved.
- If a feature is objected by anyone, it needs to be discussed within the community. If no resolution is found, ubuntustudio-core team, whose responsibility lies in upholding the quality and integrity of Ubuntu Studio, has last say .
- If a feature spec will break something in Ubuntu, it may be disapproved by the ubuntustudio-core team. Also, it will most probably be disapproved later by Ubuntu devs anyway.
UbuntuStudio/DevEvents/FeatureDefinition (last edited 2014-05-08 09:42:06 by 83)