Changes

Talk:Features/Policy (view source)

Revision as of 07:04, 4 December 2009

119 bytes removed , 07:04, 4 December 2009

no edit summary

Line 4: Line 4:

== Propose a Feature into an activity ==

−

~~As with the Features~~ for ~~the~~

+

The Process for inclusion of an Activity Feature into an activity release is similar to that of a Feature for Sucrose. The Feature must have an owner, there must be community consensus etc. There are two main differences:

−

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

+

* As activities are not part of the Sucrose do not have to follow the dates of the development cycle. The schedule for Feature inclusion is dependent on the maintainer of an activity. The merging of the Feature Code happens between the Feature Owner and the Activity Mainteiner, too.

−

+

* The Activity Feature Process is handled by a designated activity team member. Like the Release Manager is responsible for the Sucrose Feature Process, the activity team member is responsible for managing the Activity Feature Process.

−

~~They can range from~~ a ~~new capability for a Sugar activity to a global change to the toolkit.~~

−

~~or as part of the on-going Sugar~~ activity ~~update process~~. ~~(The developer will work with~~ the ~~module maintainer, who~~ is ~~ultimately~~ responsible ~~to review and merge~~ the ~~new feature.) Work on new features will be tracked in the wiki and in bugs.sugarlabs.org (where modules are referred to as "components" and features are referred to as "enhancements") 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~~.)

Erikos

3,267

edits