Changes

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. '''Note:''' bugs are not features. We use the [http://bugs.sugarlabs.org bug tracker] to report and monitor bugs.

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. '''Note:''' bugs are not features. We 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 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 will work with the module maintainer, who is ultimately responsible to review and merge the new feature.) Work on new features will be tracked in the wiki and in bugs.sugarlabs.org (where modules are referred to as "components" and features are referred to as "enhancements") 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.)

Furthermore this process describes the steps a Feature owner needs to fulfill to propose the Feature to be part of a Sucrose release cycle and to include it in a Sucrose release.  

 

 

=== Who is responsible for this process? ===

=== Who is responsible for this process? ===