3,267
edits
Changes
Jump to navigation
Jump to search
Line 105:
Line 105: − + − Yes. + + + + − + − + − + + Line 118:
Line 122: + +
→Are there specific things I should consider when proposing a feature?
# 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? ==
== Things you should consider when proposing a feature ==
# How does it impact learning?
#* What is the benefit to a learner?
# How usable and useful is this feature to a young learners?
#* The majority of our users are '''12 years old or under''', and have little computing experience. When proposing a new feature you should have your audience in mind.
# How well does this fit into a classroom environment?
# 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.
#* 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?
# Don't forget the current user base.
#* The majority of our users are '''12 years old or under''', and have little computing experience.
#* Keep in mind that Sugar has already a large user base (1.000.000 learners). There shouldn't be additions or rewrites for the sake of it. This does not mean that the platform stands still and we only do stabilizing work. Good practice is for example to backup your proposal by requests from the field.
# Does it scale?
# Does it scale in deployments?
#* Anything that involves a setup process of a person touching each computer is not suitable for deployments.
#* 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?
#* 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?
#* 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 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.
#* 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?
# 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.
#* 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.
#* 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.
#* 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?
# 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.
#* 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.