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 it 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. The feature owner is responsible for watching any owned pages for state changes, using the wiki watch feature.

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

Are there specific things I should consider when proposing a feature?

Yes.

1. 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.
2. How usable and useful is this feature to a young child?
   • The majority of our users are 12 years old or under, and have little computing experience.
3. Does it scale?
   • 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?
4. 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.
5. 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.
6. 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.

How do I propose a feature idea, even if I can't build it myself?

Community members are encouraged to create new pages for features that enhance or improve Sugar. Anyone can propose new features for Sugar by following these steps:

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

These pages do not have to be complete and are useful for brainstorming or work in process.

How do I propose a feature I'm going to help build or own?

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 which 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

• 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.
• A blank template is available at Features/Feature Template

What does the feature form look like?

Feature Template

How does a feature get accepted?

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

What do I need to do over the course of the release cycle?

1. Feature pages should be updated to reflect the current status of the feature by the following milestones on the Release schedule:
   • Alpha Freeze --features not 100% complete at alpha should be updated no less than every two weeks
   • Beta Freeze
2. One week prior to Beta Freeze all features will evaluated based on test results to date
3. 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).
4. The Release Manager will send individual reminders and announcements to sugar-devel list as necessary
5. 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
6. Reminders to developers about upcoming feature deadlines will be sent to sugar-devel
7. Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on sugar-devel

During the process

How do I show the status of a feature I own?

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.