Difference between revisions of "Features/Policy"
(Created page with '<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show …') |
|||
| Line 19: | Line 19: | ||
== Is ''<XXX>'' a feature? == | == 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? == | == What does the feature process ''look'' like? == | ||
Revision as of 06:10, 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?
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?
- How do I propose a feature I'm going to help build or own?
- What does the feature form look like?
- How does a feature get accepted?
- What do I need to do over the course of the release cycle?
During the process
- How do I show the status of a feature I own?
- Are there deadlines for features?
- What is the process for dropping a feature?