[IAEP] [ANNOUNCE] Feature Policy updated
Simon Schampijer
simon at schampijer.de
Fri Nov 27 13:40:26 EST 2009
Dear Sugar community,
the Feature policy [1] has been updated.
* Why this process *
Let me quote the first paragraph to exaplin what this policy is for:
"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."
* Who can propose a feature *
Basically, anyone can propose a feature following the guidelines in the
wiki page [2]. This feature can be emerge from a deployment need or a
teacher request etc. You do not need to be able to build the feature
yourself. Of course to be making it's way into a release someone needs
to own the feature and build it. The way to propose a feature to be
included in the release cycle and how it gets included in a stable
release is described at [3].
* Backup up by the community *
The proposer of the feature has to get feedback from the community. This
includes technical feedback, feedback from the deployments etc. See as
well in the last paragraph about which points the community might care.
Of course there will be some different opinions in the community - in
general there should be more YES than NO in the community for a feature
to be able to get into a Sugar release.
* Design *
What we enforce is the work with the Design Team when proposing a
feature that includes UI changes or adds a new UI. We want to keep the
UI consistent and the quality high. As the Sugar environment is mainly
about the UI and a clear work flow this is very important.
* Things you should consider when proposing a feature *
There are several things you should consider when proposing a feature
for the Sugar learning platform [4]. How does it impact learning? How
usable and useful is this feature to a young learners? How well does
this fit into a classroom environment? [...] These are good guidelines
to make a Feature a success.
Keep the ideas and implementations coming,
Simon
PS: If you need an example of someone following the process have a look
at Aleksey's last mails [5].
[1] http://wiki.sugarlabs.org/go/Features/Policy
[2] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature
[3]
http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle
[4]
http://wiki.sugarlabs.org/go/Features/Policy#Things_you_should_consider_when_proposing_a_feature
[5] http://lists.sugarlabs.org/archive/sugar-devel/2009-November/021031.html
More information about the IAEP
mailing list