Changes

<noinclude>{{GoogleTrans-en}}{{TOCright}}

<noinclude>[[Category:Policy]]

[[Category:Feature|<Policy]]

[[Category:Feature|.Policy]]

</noinclude>

</noinclude>

== Why does this process matter or why should I care? ==

== Why does this process matter or why should I care? ==

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.  

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.  

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. We are currently in discussions on how this process can be used by activities, too. As Activities are not part of Sucrose (the Sugar platform), they do not need to follow the release cycle. Stay tuned on updates to this process regarding activities.

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.  

 

We are currently in discussing on how this process can be used by activities, too. As Activities are not part of Sucrose (the Sugar platform), they do not need to follow the release cycle. Stay tuned on updates to the Feature process regarding activities.

 

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

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

The person responsible for managing the Feature Process is our community-designated Release Manager. (The current Release Manager is [http://wiki.sugarlabs.org/go/User:Erikos Simon Schampijer].)

The person responsible for managing the Feature Process is our community-designated Release Manager.

==== Roles ====

==== Roles ====

== What is a feature? ==

== What is a feature? ==

A feature is defined as a significant change or enhancement to the version of Sugar currently under development that may or may not include new packages.

A feature is defined as a significant change or enhancement to the version of Sugar currently under development that may or may not include new packages. Bugs are not features. We use the bug tracker to report and monitor bugs.  

Sugar features are usually considered to meet one or more of the following objectives:

Sugar features are usually considered to meet one or more of the following objectives:

=== Propose a feature for addition into the release cycle ===

=== Propose a feature for addition into the release cycle ===

The final goal is to have a feature present in a stable release. There are three major steps needed on which the release manager bases his decision to accept a feature or not:

The final goal is to have a feature present in a stable release. There are three major steps needed on which the Release Manager bases his decision to accept a feature or not:

# Owner: The Feature must have a clear owner (The proposer of the feature and the owner can be the same person).

# Owner: The Feature must have a clear owner (The proposer of the feature and the owner can be the same person).

# Community consensus: There should be more YES than NO in the community for this Feature.

# Community consensus: There should be more YES than NO in the community for this Feature.

#* Send an email to sugar-devel mailing list with [FEATURE] tag in the subject asking for feedback. This is to give the community (deployments, developers, teachers etc) the chance to comment.  

#* Send an email to sugar-devel mailing list with [FEATURE] tag in the subject asking for feedback. This is to give the community (deployments, developers, teachers etc) the chance to comment.  

#* If your feature adds UI or changes the current UI please add as well the [DESIGN] tag to the subject. The Design Team should be involved in the discussion to guarantee a consistent design and a consistent work flow in Sugar. When presenting the feature to the release manager the design must not be ready but the discussion should have been started.

#* If your feature adds UI or changes the current UI please add as well the [DESIGN] tag to the subject. Please add the flag as well if the work flow does change or new ones are added. The Design Team should be involved in the discussion to guarantee a consistent design and a consistent work flow in Sugar. When presenting the feature to the release manager the design does not have to be fully completed but the discussion should have been started.

# Documentation: In order to be considered an official feature accepted for the next Sugar release, the feature should be formally documented on a separate wiki page. The wiki page is the same page than the one from above (a blank template is available at [[Features/Feature Template]]). Please make sure it includes the following information.

# Documentation: In order to be considered an official feature accepted for the next Sugar release, the feature should be formally documented on a separate wiki page. The wiki page is the same page than the one from above (a blank template is available at [[Features/Feature Template]]). Please make sure it includes the following information.

#* Summary of the feature

#* Summary of the feature

* Complete the feature: The feature must be feature complete by the ''Feature Freeze''.

* Complete the feature: The feature must be feature complete by the ''Feature Freeze''.

* Inclusion: The owner of the feature is responsible that the Feature is latest present into the release at Feature Freeze. Please follow the [[Development_Team/Code_Review|development team guidelines]] to make this happen.

* Inclusion: The owner of the feature is responsible that the Feature is present at latest in the release at Feature Freeze. The developer will work with the module maintainer (e.g. Tomeu for Sugar), who is ultimately responsible to review and merge the new feature. Please follow the [[Development_Team/Code_Review|development team guidelines]] to make this happen.

* Feature pages: The feature page should be updated to reflect the current status of the feature. At ''Feature Freeze'': The "How To Test" and "User Experience" section must be completed so that testing of that feature can begin. The section 'Release Notes' must be completed when the writing of the release notes begins.

* Feature pages: The feature page should be updated to reflect the current status of the feature. At ''Feature Freeze'': The "How To Test" and "User Experience" section must be completed so that testing of that feature can begin. The section 'Release Notes' must be completed when the writing of the release notes begins.