Line 16: |
Line 16: |
| 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. | | 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:
| + | Sugar features are usually considered to meet one or more of the following objectives: |
| | | |
− | # Highly user visible changes (beyond artwork or theme changes) | + | # Highly user-visible changes (beyond artwork or theme changes) |
| # Improvements or changes that require non-trivial cross-package integration | | # Improvements or changes that require non-trivial cross-package integration |
− | # Exciting new capabilities we can trumpet Sugar having -- some of this is good public relations. Some examples might include: | + | # 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 | + | #* Adding of new functionality to the Sugar platform, for example: version support in the datastore; file-sharing; etc. |
| #* Work Sugar contributors are doing upstream as part of their work for Sugar | | #* 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 | | #* New features from upstream that we are making available in Sugar for the first time |
Line 27: |
Line 27: |
| # Noteworthy enough to call out in the release notes | | # 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. | + | Similarly, Activity features meet a similar set of criteria: |
| + | |
| + | # Highly user-visible changes (beyond artwork or theme changes) |
| + | # Improvements or changes that require non-trivial cross-package integration |
| + | # Exciting new capabilities: |
| + | #* Adding of new functionality, for example: support for a new ebook format |
| + | #* Adding a new activity area, for example: a multimedia editor |
| + | #* Better leverage of the Sugar platform, for example: Journal integration for Scratch |
| + | # 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. |
| | | |
| # Is this change very visible to end users? | | # 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. | | #* In this case "end user" means "someone in the audience for this change", which could be Sugar users, developers, or system administrators. |
| # Does this change require intervention? | | # Does this change require intervention? |
− | #* This might be a configuration file format change, or something else that will perturb unsuspecting end users. | + | #* 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. | | #* A change that requires a very simple intervention to revert behavior is not necessarily a feature. |
| # Is this something that will interest the lay press? | | # Is this something that will interest the lay press? |