Changes

Jump to navigation Jump to search
624 bytes added ,  03:27, 25 November 2009
no edit summary
Line 2: Line 2:  
[[Category:Feature|<Policy]]
 
[[Category:Feature|<Policy]]
 
</noinclude>
 
</noinclude>
 +
 +
= Why does this process matter or why should I care? =
 +
The main goal of the feature process is to phrase out the ideas on how Sugar should evolve that are floating around in the community. These can be requests from the field or individual propositions on how to enhance the learning platform.
 +
 +
Once the idea is written out in a wiki page (following the process described in detail below) and a maintainer is found who will be working on this feature, it can be proposed to be part of a Sucrose release cycle. The work on that feature will be tracked during the cycle and if finished in time it will find it's way in the Sucrose stable release.
 +
 +
Finally, having new features listed for a release helps to actively promote new Sugar features to the world. As a Sugar developer you benefit from this promotion by attracting testers and more users to make it better.
 +
 +
== Is there a way to get an exception from this policy? ==
 +
Features not meeting the guidelines above may be brought to the Release Manager for review.
 +
 +
== Who is responsible for this process? ==
 +
The person responsible for managing the release, the Release Manager, is designated by the community to fulfill the task.
 +
 +
The feature owner is responsible for watching any owned pages for state changes, using the wiki watch feature.
 +
 +
Current Release Manager: Simon Schampijer
 +
    
= I want to know... =
 
= I want to know... =
Line 156: Line 174:     
Partially completed features can still be listed as ''accepted'' for the upcoming release if the wiki page describing the feature is tailored to reflect the completed work.  Dropped features can be proposed again for inclusion in the next release.
 
Partially completed features can still be listed as ''accepted'' for the upcoming release if the wiki page describing the feature is tailored to reflect the completed work.  Dropped features can be proposed again for inclusion in the next release.
  −
= Policy questions =
  −
== Why does this process matter or why should I care? ==
  −
We want to actively promote new features to the world. As a Sugar developer you benefit from this promotion by attracting testers and more users to make it better.
  −
  −
== Is there a way to get an exception from this policy? ==
  −
Features not meeting the guidelines above may be brought to the Release Manager for review.
  −
  −
== Who is responsible for this process? ==
  −
The person responsible for managing the release, the Release Manager, is designated by the community to fulfill the task.
  −
  −
The feature owner is responsible for watching any owned pages for state changes, using the wiki watch feature.
  −
  −
Current Release Manager: Simon Schampijer
 
3,267

edits

Navigation menu