Changes

Jump to: navigation, search

Features/Policy

78 bytes added, 12:46, 30 November 2009
Why does this process matter or why should I care?: better destinction between developer and maintainer?
The main goal of the feature policy is to make systematic and predictable the process by which community ideas on how Sugar should evolve get transformed into actionable proposals. These ideas—new features—can be requests from the field or individual propositions on how to enhance the Sugar learning platform. They can range from a new capability for Sugar activity to a global change to the toolkit. '''Note:''' bugs are not features. We should continue to use the [http://bugs.sugarlabs.org bug tracker] to report and monitor bugs.
Once the idea is described in a [[Features/Feature_Template|wiki page]] (following the process described in detail below) and a maintainer developer is found who will work on the idea, it can be proposed to be part of a Sucrose release cycle (in the case of platform features) or as part of the on-going Sugar activity update process. (The developer with work with the module maintainer to merge the new feature.) In either case, work on new features will be [http://bugs.sugarlabs.org tracked] and, in the case of platform features, if finished in time, they will find their way in the Sucrose stable release (See [[0.88/Roadmap]] for details of the current release cycle.)
== Who is responsible for this process? ==

Navigation menu