3,267
edits
Changes
→Things you should consider when proposing a feature
# Don't forget the current user base.
# Don't forget the current user base.
#* 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, if possible.
#* 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, if possible.
# Does it scale in deployments?
# 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.
#* 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.