Features/Policy: Difference between revisions

Erikos (talk | contribs)
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<noinclude>{{GoogleTrans-en}}{{TOCright}}
<noinclude>[[Category:Policy]]
[[Category:Feature|<Policy]]
[[Category:Feature|.Policy]]
</noinclude>
</noinclude>


Line 9: Line 9:


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


=== 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 ====
Line 83: Line 85:


=== 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
Line 153: Line 155:
* 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.