FeatureDefinition
|
Size: 1629
Comment:
|
← Revision 20 as of 2014-05-08 09:42:06 ⇥
Size: 1801
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| ||<style="width: 15%"> week 1-4 || discuss on the mail list and irc channels on feature additions || || week 4-5 || finalize [[UbuntuStudio/Blueprints|blueprints]] at around week 4, and have them approved before FeatureDefinitionFreeze || |
||<style="width: 15%"> week 1-8 || Discuss on mail list, irc and social channels about feature additions. Collect ideas on wiki pages, and then create blueprints. || || week 8-9 || finalize [[UbuntuStudio/Blueprints|blueprints]] at around week 8, and have them approved by ubuntustudio-core team before FeatureDefinitionFreeze || |
| Line 17: | Line 17: |
| Anyone can suggest a feature change/addition. But, to make it a reality, someone needs to implement it. Usually it is the same person that makes the suggestion. | Anyone can suggest a feature change/addition. But, to make it a reality, someone also needs to implement it. Safest bet is that whoever makes the suggestion also works on implementing it. |
| Line 21: | Line 21: |
| Blueprints should in first hand be created by members in one of the restricted Ubuntu Studio dev teams (ubuntustudio-core, ubuntustudio-dev, ubuntustudio-art, etc). | Blueprints are created for projects, and the blueprint should be created by the driver of that project (typically ubuntustudio-dev), or the owner (ubuntustudio-core). |
| Line 25: | Line 25: |
| * If a feature spec is not objected, it is automatically approved. * If a feature breaks something in Ubuntu, it may be disapproved by the ubuntustudio-core team. Also, it will most probably be disapproved later by Ubuntu devs anyway. * If a feature is objected by anyone, it needs to be discussed within the community. ubuntustudio-core team has last say - whose responsibility lies in upholding the quality and integrity of Ubuntu Studio. |
* 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, or in other ways does not comply to Debian and/or Ubuntu policies, it may be automatically disapproved by the ubuntustudio-core team. |
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 on wiki pages, and then create blueprints. |
week 8-9 |
finalize blueprints at around week 8, and have them approved by ubuntustudio-core team 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 also needs to implement it. Safest bet is that whoever makes the suggestion also works on implementing it.
Creating Blueprints
Blueprints are created for projects, and the blueprint should be created by the driver of that project (typically ubuntustudio-dev), or the owner (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, or in other ways does not comply to Debian and/or Ubuntu policies, it may be automatically disapproved by the ubuntustudio-core team.
UbuntuStudio/DevEvents/FeatureDefinition (last edited 2014-05-08 09:42:06 by 83)