1,285
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − + − + − + − Once the idea is described in a [[Features/Feature_Template|wiki page]] (following the process described in detail below) and a maintainer 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. 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? ==+ − 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].+ − + − + + + + + + + + + + + + + + + + − + Line 47:
Line 61: − + − + − * Propose a feature to the community+ − * Find/name an owner and propose the feature for addition into the release cycle+ − * Finish the feature by the ''Feature Freeze'' and include it into the release+ − + − + Line 64:
Line 78: − + + + − + − + − + − + Line 110:
Line 126: − + Line 133:
Line 149: − + − + − + − + Line 154:
Line 170: − +
→Who is responsible for this process?
<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. 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.
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 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.
'''Note:''' For more background on FOSS project development, please refer to Karl Fogel's [http://producingoss.com/ Producing Open Source Software]
= What is a feature? =
=== Who is responsible for this process? ===
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 person responsible for managing the Feature Process is our community-designated Release Manager.
==== 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, the design team and the Sugar community.
* the proposer (or "owner") of the idea is the one that proposes the feature and completes the new feature proposal as described below. The owner may want to follow the development and provide feedback throughout the process;
* the developer of the idea is the one that implements the idea and follows the process to inclusion in a release;
* the maintainer of the module is the one that reviews any code that needs to be merged for a feature;
* the design team is responsible for ensuring the overall consistency and quality of the Sugar experience; They will provide feedback during the process; and
* the community provides feedback throughout the process, but especially at the stage where by we decide which new-feature proposals to pursue.
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? ==
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:
# Highly user-visible changes (beyond artwork or theme changes)
# Highly user-visible changes (beyond artwork or bug fixes)
# Improvements or changes that require non-trivial cross-package integration
# Improvements or changes that require non-trivial cross-package integration
# Exciting new capabilities we can trumpet Sugar having—some of this is good public relations. Some examples might include:
# Exciting new capabilities we can trumpet Sugar having—some of this is good public relations. Some examples might include:
#* 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 that category. There are three main steps needed to go from your original idea to a feature present in a stable release:
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:
# Propose a feature to the community;
# Find/name an owner and propose the feature for addition into the release cycle or activity development cycle; and, in the case of platform features,
# 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 can't build it yourself. Of course, the feature needs an owner to work on it during the release cycle to make it into a release. If the community agrees on the need for the feature, their are good chances to find resources to do that task. For proposing a feature you need to do (these pages do not have to be complete and are useful for brainstorming or work in process):
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:
# Copy the markup from the [[Features/Feature Template]]
# Copy the markup from the [[Features/Feature Template]]
#* The template adds <code><nowiki>[[Category:Feature Page Incomplete]]</nowiki></code> to the wiki page. This means that it is not part of the release cycle. See below on how to request inclusion.
#* The template adds <code><nowiki>[[Category:Feature Page Incomplete]]</nowiki></code> to the wiki page. This means that it is not part of the release cycle. See below on how to request inclusion.
# Put a watch on your page by clicking the watch link so you can see changes other people make to your page.
# Put a watch on your page by clicking the watch link so you can see changes other people make to your page.
#* You must be logged in to do this.
#* '''Note:''' You must be logged in to do this.
'''Note:''' Feature pages do not have to be complete as they are useful for brainstorming and for describing work in process.
If you do not work on the feature itself and are looking for other people that might be interested, you can mail the sugar devel mailing list and discuss it there. The feature page stated above should be filled out as good as possible though to have a base for the debate.
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:
# 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
If the Feature is accepted the Release Manager moves the Feature to Feature Accepted <version>, such as, [[:Category:Feature Accepted {{Upcoming Stable Release}}]]. If the feature is denied the Release Manager moves the Feature to [[:Category:Feature Page Incomplete]] for rework or future resubmission.
If the Feature is accepted the Release Manager moves the Feature to Feature Accepted <version>, such as, [[:Category:Feature Accepted {{Upcoming Stable Release}}]]. If the feature is denied the Release Manager moves the Feature to [[:Category:Feature Page Incomplete]] for rework or future resubmission.
== Things you should consider when proposing a feature ==
=== Things you should consider when proposing a feature ===
# How does it impact learning?
# How does it impact learning?
#* 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]].
* 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.
== 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: