Changes

</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. They can range from a new capability for a 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.

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 a 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.

'''Note:''' For more background on FOSS project development, please refer to Karl Fogel's [http://producingoss.com/ Producing Open Source Software]

'''Note:''' For more background on FOSS project development, please refer to Karl Fogel's [http://producingoss.com/ Producing Open Source Software]

== Who is responsible for this process? ==

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

In the case of features impacting the Sugar platform itself, the person responsible for managing the release is our community-designated Release Manager. (The current Release Manager is [http://wiki.sugarlabs.org/go/User:Erikos Simon Schampijer].)

In the case of features impacting the Sugar platform itself, the person responsible for managing the release is our community-designated Release Manager. (The current Release Manager is [http://wiki.sugarlabs.org/go/User:Erikos Simon Schampijer].)

In the case of features impacting individual activities, the person responsible is the activity maintainer. The list of maintainers is available on the activity page in [http://activities.sugarlabs.org ASLO].

In the case of features impacting individual activities, the person responsible is the activity maintainer. The list of maintainers is available on the activity page in [http://activities.sugarlabs.org ASLO].

=== Roles ===

==== Roles ====

In addition to the Release Manager, there are five other distinct roles in the new-feature process: the proposer of the idea; the developer of the idea; the maintainer of the relevant module and the Sugar community.

In addition to the Release Manager, there are five other distinct roles in the new-feature process: the proposer of the idea; the developer of the idea; the maintainer of the relevant module and the Sugar community.

As noted above, the Release Manager is the one that sets and enforce the policy for features, including setting dates, formalizing processes, etc.

As noted above, the Release Manager is the one that sets and enforce the policy for features, including setting dates, formalizing processes, etc.

= 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.

#* The lay press in this case includes Education-oriented sites.

#* The lay press in this case includes Education-oriented sites.

= Starting the process =

== Starting the process ==

Before starting the process you should have read the feature definition from above and made sure the idea you want to propose does fit into one of the categories. Subsequently, there are three steps needed to go from your original idea to a feature present in a stable release of Sugar:

Before starting the process you should have read the feature definition from above and made sure the idea you want to propose does fit into one of the categories. Subsequently, there are three steps needed to go from your original idea to a feature present in a stable release of Sugar:

# Finish the feature by the ''Feature Freeze'' such that it is included in the release.

# Finish the feature by the ''Feature Freeze'' such that it is included in the release.

== Propose a feature ==

=== Propose a feature ===

Community members are encouraged to create new pages for features that enhance or improve Sugar. Anyone can propose new features for Sugar, even if you cannot build it yourself. Of course, every feature needs an owner to work on it during the release cycle. If the community agrees on the need for the feature, we will try to find resources to work on it. For proposing a feature you need to:

Community members are encouraged to create new pages for features that enhance or improve Sugar. Anyone can propose new features for Sugar, even if you cannot build it yourself. Of course, every feature needs an owner to work on it during the release cycle. If the community agrees on the need for the feature, we will try to find resources to work on it. For proposing a feature you need to:

If you cannot work on the feature yourself and are looking for other people that might be interested, you should mail the sugar-devel mailing list and discuss it there. The feature page described above should be filled out as completely as possible though to have a base for subsequent discussion.

If you cannot work on the feature yourself and are looking for other people that might be interested, you should mail the sugar-devel mailing list and discuss it there. The feature page described above should be filled out as completely as possible though to have a base for subsequent discussion.

== 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:

#* The majority of our users use low-specification computers, so keeping things small and fast will greatly increase the size of your userbase, the support from fellow Sugar developers, and the eventual success of your work.

#* The majority of our users use low-specification computers, so keeping things small and fast will greatly increase the size of your userbase, the support from fellow Sugar developers, and the eventual success of your work.

= During the process =

== During the process ==

== What do the feature owner need to do over the course of the release cycle? ==

=== What do the feature owner need to do over the course of the release cycle? ===

The feature is included in the release cycle and follows the [[Development_Team/Release/Roadmap | Release schedule]].

The feature is included in the release cycle and follows the [[Development_Team/Release/Roadmap | Release schedule]].

* 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.

== Important dates ==

=== Important dates ===

* New features may be proposed (using the guidelines above) and accepted no later than the ''Feature Acceptance'' milestone. Of course you can still propose a feature for an upcoming release.

* New features may be proposed (using the guidelines above) and accepted no later than the ''Feature Acceptance'' milestone. Of course you can still propose a feature for an upcoming release.

* New features must be feature complete or close enough to completion by ''Feature Freeze'' that a majority of its functionality can be suitably tested--the "feature is testable".  

* New features must be feature complete or close enough to completion by ''Feature Freeze'' that a majority of its functionality can be suitably tested--the "feature is testable".  

* Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on sugar-devel.

* Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on sugar-devel.

== What is the process for dropping a feature? ==

=== What is the process for dropping a feature? ===

A feature will be proposed for a vote to be dropped from the ''Accepted Feature'' list by the Release Manager if one of the following occurs:

A feature will be proposed for a vote to be dropped from the ''Accepted Feature'' list by the Release Manager if one of the following occurs: