Line 1: |
Line 1: |
− | {{TOCright}} | + | <noinclude>[[Category:Policy]]</noinclude>{{draft}} |
| | | |
− | == ASLO auto checking == | + | == Technical policy == |
| | | |
− | * unique ''bundle_id'' activity.info field value
| + | All technical checks will happen [[Platform_Team/Recipe_Lint|automatically]] while uploading activities. |
− | * unique ''name'' activity.info field value
| |
− | * unique ''icon'' activity.info image file
| |
− | * ''license'' activity.info field value has short names that conform fedora good licences lists: [http://fedoraproject.org/wiki/Licensing#Good_Licenses software], [http://fedoraproject.org/wiki/Licensing#Good_Licenses_2 documentation] and [http://fedoraproject.org/wiki/Licensing#Good_Licenses_3 content].
| |
| | | |
− | == Additional technical policy for editors == | + | == Guidelines for accepting an activity == |
| | | |
− | * ... | + | * ''Must Start/Stop cleanly'' |
| + | ** When stopping must stop gracefully - not stay in memory. |
| + | * ''CPU and Memory usage'' |
| + | ** Usage must be proportional to functionality |
| + | ** Must not completely tie up the machine |
| + | * ''Interface'' |
| + | ** Conform to Sugar standards? |
| + | ** Icons to meet sugar colour guidelines |
| + | ** Frame key must work from within the activity |
| + | ** Must fit within screen size of the XO’s |
| + | * ''Journal'' |
| + | ** Is there save functionality and does it interact with the Journal well? |
| + | ** Are file types registered with SugarOS correctly? |
| + | * ''Checks'' |
| + | ** Black and white (high contrast screen) |
| + | ** Sound |
| + | ***Does sound behave? |
| + | ****Stutter |
| + | ****lock up sound card |
| + | ** Collaboration |
| + | ***Must work if button is there |
| + | ***Maximum number of collaborators |
| + | ***Test with 3 or more? |
| + | * ''Bugs (for updated activities)'' |
| + | ** Are there any regressions in old functionality? |
| + | ** How functional is new functionality? |
| + | * ''Download size of application must be reasonable compared to similar applications'' |
| + | ** functionality |
| + | * ''For activities webpage'' |
| + | ** Must have reasonable explanation of purpose for the “more about this activity” field |
| + | ** Must have release notes |
| + | ** Must be categorised correctly |
| + | * Versions of Sugar |
| + | ** Do we assume the developer has tested on all versions they say it works on? --[[User:RafaelOrtiz|RafaelOrtiz]] 20:48, 18 February 2011 (EST) At least that he sets the flag correctly on ASLO. |
| + | ** Tester approving activity tests on olpc stable builds? |
| + | ** Who tests on SoaS and what version? |
| + | * Must tell user if the activity is using web? collecting user data? |
| + | * Must have I18n support (i.e gettext generated .POT with ./setup.py genpot) |
| + | --[[User:RafaelOrtiz|RafaelOrtiz]] 20:48, 18 February 2011 (EST) We must focus in testing for diferent versions of sugar, olpc. soas an use different sugar versions, generally newer than Sugar 0.82 |
| + | |
| + | ---- |
| + | |
| + | Sorry, but keeping all these "Must"s, what ASLO is supposed to be? A place to host activities developed by well skilled coders, QAed by well skilled engineers, released by well skilled project managers? Is it about Sugar or something else? If I got Sugar purpose right, Sugar is about learning via doing, it is mostly impossible to do something well formed right after starting. ASLO should respect experimenters and their decision about quality (ready to share) of the code. At the same time, there are bunch of side ways how to mark activities that satisfy all these "Must"s - editors pick up and special collections. [[User:Alsroot|alsroot]] 07:29, 26 September 2011 (EDT) |
| | | |
| == Non-technical policy == | | == Non-technical policy == |
− | | + | {{:{{PAGENAME}}/Non-Technical}} |
− | * ...
| |
| | | |
| == Resources == | | == Resources == |