3,267
edits
Changes
→Starting the process: Rewrite of this section (still in progress)
= Starting the process =
= 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
== How do I propose a feature idea, even if I can't build it myself? ==
== 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 by following these steps:
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):
# Copy the markup from the [[Features/Feature Template]]
# Copy the markup from the [[Features/Feature Template]]
#* You must be logged in to do this.
#* 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.
== How do I propose a feature I'm going to help build or own? ==
== 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 which includes the following information.
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.
# Summary of the feature
# Summary of the feature
# Link to documentation
# Link to documentation
# Important information for release notes
# 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.
* 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.
== How does a feature get accepted? ==
=== 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.
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.
# important to track prior to feature freeze and could affect timeliness of release
# 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? ==
=== What do I need to do over the course of the release cycle? ===
# Feature pages should be updated to reflect the current status of the feature by the following milestones on the [[Development_Team/Release/Roadmap | Release schedule]]:
# Feature pages should be updated to reflect the current status of the feature by the following milestones on the [[Development_Team/Release/Roadmap | Release schedule]]:
#* Alpha Freeze --features not 100% complete at alpha should be updated no less than every two weeks
#* Alpha Freeze --features not 100% complete at alpha should be updated no less than every two weeks
# Reminders to developers about upcoming feature deadlines will be sent to sugar-devel
# 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
# Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on sugar-devel
== Are there specific things I should consider when proposing a feature? ==
Yes.
# 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.
# 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.
# 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?
# 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.
# 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.
# 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 =
= During the process =