Features/Policy

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 your feature better.

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 current Release Manager is Simon Schampijer.

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.

Features are usually considered to meet one or more of the following objectives:

1. highly user visible changes (beyond artwork or theme changes)
2. improvements or changes that require non-trivial cross-package integration
3. exciting new capabilities we can trumpet Sugar having -- some of this is good public relations. Some examples might include:
   • adding of new functionality to the Sugar platform Examples: version support in the datastore, file-sharing
   • work Sugar contributors are doing upstream as part of their work for Sugar
   • new features from upstream that we are making available in Sugar for the first time
4. significant enough that if not completed properly or without a proper backup plan could delay the release
5. noteworthy enough to call out in the release notes

It's sometimes easy to mistake new packages, or enhancements, for features. Features have a very specific definition, but here are some questions to ask yourself before engaging the feature process.

1. Is this change very visible to end users?
   • In this case "end user" means "someone in the audience for this change", which could be Sugar users, developers, or system administrators.
2. Does this change require intervention?
   • This might be a configuration file format change, or something else that will perturb unsuspecting end users.
   • A change that requires a very simple intervention to revert behavior is not necessarily a feature.
3. Is this something that will interest the lay press?
   • The lay press in this case includes Education-oriented sites.

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:

• 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

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):

1. Copy the markup from the Features/Feature Template
   • click here to load it
   • select all the markup and copy
2. Add a new wiki subpage named Features/Your feature name and paste the template markup into it.
3. Add details for each of the sections required in the Template.
   • The template adds [[Category:Feature Page Incomplete]] to the wiki page. This means that it is not part of the release cycle. See below on how to request inclusion.
4. 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.

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.

Propose a feature for addition into the release cycle

The final goal is to have a feature present in a stable release. Once the ownership is sorted out and the page is filled out correctly you can propose it to the release manager for inclusion into the process. The proposer of the feature and the owner can be the same person.

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.

1. Summary of the feature
2. A designated owner with a link to Sugar home page. The owner is responsible for:
   1. making sure the feature is completed according to the schedule
   2. communicating periodic status
   3. attending feature status meetings
3. Current status
   1. last updated
   2. estimated percentage of completion
4. Description of the new feature
5. Detailed explanation of what the new feature will do and how it will be implemented
6. Benefit to Sugar
7. Scope
8. How To Test
9. Dependencies--on other packages or features
10. Contingency plan
11. Link to documentation
12. Important information for release notes
13. Put a watch on your page so you are notified when its category changes. You must be logged in, then click the watch link at the top of the page.

Once the feature owner believes that the feature is ready for presentation to the Release Manager for acceptance move your feature from Category:Feature Page Incomplete to Category:Feature Ready for Release Manager. The Release Manager will then do the sanity check.

Acceptance of a feature

Acceptance by the Release Manger is a sanity check, presumed in most cases to be a formality, to ensure that new features compliment Sugar guidelines and is manageable, prior to publicizing as officially targeted for the next release.

Feature acceptance is agreement by the Release Manager that a particular feature is:

1. consistent with the goals and policies of Sugar
2. supported by the Sugar community
3. suitable for listing as an Official Feature of the next release of Sugar
4. important to track prior to feature freeze and could affect timeliness of release

If the Feature is accepted the Release Manager moves the Feature to Feature Accepted <version>, such as, Category:Feature Accepted 0.114. If the feature is denied the Release Manager moves the Feature to Category:Feature Page Incomplete for rework or future resubmission.

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 Release schedule.

• Complete the feature: The feature must be completed by the Feature Freeze.

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

• One week prior to Beta Freeze all features will be evaluated based on test results to date

• At Beta Freeze all feature pages should be at 100% completion, and if necessary, the feature page adjusted to reflect everything completed (so as to reflect 100% completion).

Things you should consider when proposing a feature

1. How does it impact learning?
   • What is the benefit to a learner?
2. How usable and useful is this feature to a young learners?
   • The majority of our users are 12 years old or under, and have little computing experience. When proposing a new feature you should have your audience in mind.
3. How well does this fit into a classroom environment?
   • Of course, Sugar is also designed for use outside of the classroom, but those features that can really enhance the classroom experience are key to increasing the adoption of Sugar.
4. Don't forget the current user base.
   • Keep in mind that Sugar has already a large user base (1.000.000 learners). There shouldn't be additions or rewrites for the sake of it. This does not mean that the platform stands still and we only do stabilizing work. Good practice is for example to backup your proposal by requests from the field, if possible.

1. Does it scale in deployments?
   • Anything that involves a setup process of a person touching each computer is not suitable for deployments.
   • Are there technical aspects which might make your feature workable with a set of 10 computers, but useless with a set of 100? 1000? 10000?
2. Does it present technicalities to the deployer?
   • If so, you may be excluding them from using this feature. Unfortunately, many deployments are limited in terms of their technical capabilities, especially when dealing with Linux/open source technologies.
   • If you can document a technical process in simple terms on a short wiki page, then it may be a realistic task for deployment teams to undertake. But keep in mind that the reader likely does not understand exactly what they are doing, so it needs to be a copy-paste type process.

1. Does it rely on (or use) infrastructure or star-style connectivity?
   • If your feature relies or uses networking to talk to some kind of centralized server, then it's probably going to get overloaded after your feature gains adoption in our large user base.
   • Deployers are likely to disable this part of your feature due to the painfully high latencies and costs of internet connections throughout the developing world.
   • If networking is a core part of your feature then make sure it is replicable, e.g. on the OLPC XS school server. Make sure that this process is fully documented with support channels available. For reasons of cost, latency or simply lack of connectivity, many deployments will replicate the global infrastructure you have set up and use your feature exclusively on a LAN level. If this is too difficult then they simply will not use your feature.

1. What does it require?
   • 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

• The Release Manager will send individual reminders and announcements to sugar-devel list as necessary

• A summary status for all the features targeted to a particular release will be collected on a summary page which references and briefly explains the feature. The Release Manager will maintain this page. This page will be located at: http://wiki.sugarlabs.org/go/<current release>/Feature List, such as 0.114/Feature List.

• Reminders to developers about upcoming feature deadlines will be sent to sugar-devel.

• Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on sugar-devel.

Feature pages should be updated to reflect the current status of the feature.

Are there deadlines for features?

• New features may be proposed (using the guidelines above) and accepted no later than the Feature Freeze milestone
• By the time of Alpha freeze:
  • the "Scope" section of the feature must be fleshed out and well defined so that the extent of the work to be completed is understood.
  • defined criteria for success or failure of the feature.
  • fixme: need to clarify this section more
• By the time of Alpha Freeze, test plans must be complete.
• New features must be feature complete or close enough to completion by Alpha freeze that a majority of its functionality can be suitably tested--the "feature is testable".
• At feature freeze the Release Manager will present a final feature status to the release team which the release team will review and comment on
• After final review by the Release Manager at Feature Freeze the final accepted Feature list (Release Road Map) will be publicly announced.

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:

• Feature is incomplete or not testable at Feature Freeze
• Feature owner fails to consistently provide status.

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.