Difference between revisions of "Features/Policy"

From Sugar Labs
Jump to navigation Jump to search
Line 48: Line 48:
  
 
== How do I propose a feature I'm going to help build or own? ==
 
== 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.
 +
 +
# Summary of the feature
 +
# A designated owner with a link to Sugar home page. The owner is responsible for:
 +
## making sure the feature is completed according to the schedule
 +
## communicating periodic status
 +
## attending feature status meetings
 +
# Current status
 +
## last updated
 +
## estimated percentage of completion
 +
# Description of the new feature
 +
# Detailed explanation of what the new feature will do and how it will be implemented
 +
# Benefit to Sugar
 +
# Scope
 +
# How To Test
 +
# Dependencies--on other packages or features
 +
# Contingency plan
 +
# Link to documentation
 +
# 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? ==
 
== What does the feature form look like? ==

Revision as of 05:36, 30 June 2009

I want to know...

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

What is an enhancement?

Enhancements are:

  1. Less documented improvements to a Fedora release which do follow the feature process and do not fit the feature definition below.
  2. Added to the release summary by anyone under heading of Other Enhancements. The release summary for each release lives in the following namespace: http://fedoraproject.org/wiki/Releases/<release number>/ReleaseSummary

Is <XXX> a feature?

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 desktop 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 Linux-oriented sites.

What does the feature process look like?

Starting the process

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. Add a new wiki page to http://wiki.sugarlabs.org/go/Features/<YourFeatureName>
  2. Add details for each of the sections required in the Template.
  3. Add to the bottom of 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?

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

During the process

Policy questions

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Features/Policy&oldid=31445"