<> <> 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 [[UbuntuStudio/Blueprints|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 [[FeatureSpecifications|feature specifications]] in the form of blueprints at http://launchpad.net. See our [[UbuntuStudio/Blueprints|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.