8,288
edits
Changes
Jump to navigation
Jump to search
mLine 1:
Line 1: − + + + + − == Introduction ==+ − This page is for gathering requirements for Activity inclusion on the default [[Sugar on a Stick]] image. These are the criteria we will be using to begin discussion on Activity inclusion in v.4.0, due for release at the end of October 2010.+ + + + + + + + + Line 26:
Line 37: − + + + + + + + + + + + Line 56:
Line 77: + + + + + + + + + + + + + + + + + + + − + + + + + + + + + + + + + + + + + + + + + + + − Be sure to describe:+ − + + + + + + − '''Test:''' how we can make sure that the requirement is met - what sort of testing needs to be done to verify this?+ − +
Sugar on a Stick/Activity Criteria (view source)
Revision as of 10:36, 13 July 2010
, 10:36, 13 July 2010no edit summary
<big><big><big>'''''This is a draft discussion.''' It does not reflect policy (yet) - it is our attempt to define a clear policy for inclusion for the '''4th release''' of SoaS (October 2010, as per the [http://spins.fedoraproject.org Fedora Spin] release cycle).''</big></big></big>
<noinclude>{{TOCright}}
[[Category:Sugar on a Stick]]
</noinclude>
== Introduction ==
This page describes the requirements for Activity inclusion on the default [[Sugar on a Stick]] image. This is the criteria Activities will be evaluated against when they go through the [[Sugar on a Stick release process#Feature process]].
The table of activities mapped against these criteria can be found at the [[Criteria_Status|wiki page]].
== Proposed requirements ==
== Proposed requirements ==
=== Have some clear pedagogical purpose ===
'''Rationale:''' Sugar is being developed in service of learning. We should focus on activities that can convey this message and, ideally, be readily incorporated into a lesson plan.
'''Test:''' Not really a test, but we can solicit feedback from teachers who use Sugar as to whether or not they think a particular activity has sufficient impact to merit making the short list.
'''Instructions:''' Email iaep and sur lists to solicit feedback.
=== Be installable via a package in the Fedora repositories ===
=== Be installable via a package in the Fedora repositories ===
* be able to successfully download and install the Activity from ASLO's web interface
* be able to successfully download and install the Activity from ASLO's web interface
'''Instructions:''' I can't find clear step-by-step instructions on how to get one's Activity into ASLO - can anyone else help find (or create) them?
'''Instructions:''' We've instructions for activity authors how to upload their activities [[Activity_Library/Authors|on the wiki]].
=== Be translated in Pootle ===
=== Be translated in Pootle ===
'''Rationale:''' In order to support the usage of SoaS (and SoaS remixes) by students from around the world, it is important that Activities be translateable and set up for easy localization. Pootle is the system Sugar Labs uses for localization.
'''Rationale:''' In order to support the usage of SoaS (and SoaS remixes) by students from around the world, it is important that Activities be translateable and set up for easy localization. Pootle is the system Sugar Labs uses for localization.
:Note, it may not be not absolutely essential that the localization is hosted on the Sugar Labs / OLPC Pootle instance [http://translate.sugarlabs.org/]. By way of example, see a number projects listed [[Translation_Team/Pootle_Projects#Other_projects_of_interest_.28not_locally_hosted.29|here]], including GCompris and TuxPaint where localization is handled elsewhere. It may be more of a build-process issue than an L10n issue to pull the PO files from these other sites. Requiring dual hosting of L10n doesn't sound like a win.[[User:Cjl|Cjl]] 17:04, 30 March 2010 (UTC)
'''Test:''' I am not sure what a good set of minimal "you are translateable" criteria would be. Suggestions?
'''Test:''' I am not sure what a good set of minimal "you are translateable" criteria would be. Suggestions?
:1) Simplest would be presence of the PO file in the Honey (or sometimes Fructose) projects on translate.sugarlabs.org; however, this is not always the case.
:2) Alternative acceptable (localized elsewhere) with clear documentation of how to participate in localization and get the localized PO files from their primary hosting location.
:[[User:Cjl|Cjl]] 17:14, 30 March 2010 (UTC)
'''Instructions:''' I can't find clear step-by-step instructions on how to get one's Activity into Pootle - can anyone else help find (or create) them?
'''Instructions:''' I can't find clear step-by-step instructions on how to get one's Activity into Pootle - can anyone else help find (or create) them?
: There are really only minimal instructions in the FAQ [[Translation_Team/FAQ#How_do_I_add_a_project_to_be_translated_.3F|here]], there is no question that we could use some improvement to our Translation Team documentation, including a better "Developer's Guide" entry point. [[User:Cjl|Cjl]] 17:14, 30 March 2010 (UTC)
=== Have a usage frontpage ===
=== Have a usage frontpage ===
=== Have a development frontpage ===
=== Have a development frontpage ===
'''Rationale:''' If an Activity is included on SoaS, it will be used by many people; in order to hold to the Sugar Labs principle of hackability (particularly by children), we need a good resource to get new hackers started.
'''Test:''' The ASLO page for an Activity should include a link called "get started with development" (note: this is fairly arbitrary and we may want to standardize on a better title/format) that leads to a place with instructions on how people can...
* view the source code
* download the source code
* modify the source code
* share their modifications
* view existing tickets/bugs/suggestions for things to work on
You may notice that the first 4 entries on this list map to the [http://www.gnu.org/philosophy/free-sw.html 4 essential software freedoms].
'''Instructions:''' We need instructions/examples of this. Please help!
=== Have a ticket queue ===
=== Have a ticket queue ===
'''Rationale:''' Users need a place to report bugs.
'''Test:''' The ASLO page for an Activity should include a link called "report a bug / suggest an enhancement" (note: this is fairly arbitrary and we may want to standardize on a better title/format) that leads to the "new ticket" entry for that Activity's component (which may or may not be hosted on http://bugs.sugarlabs.org, especially in the case of an upstream project such as EToys). Since we may not be standardizing on bug trackers, each Activity ASLO page should also have a link to instructions on how to file a bug, perhaps something similar to [[BugSquad/Bug Report|this tutorial]]).
'''Instructions:''' The simplest way to do this is to get a Trac component for your Activity. We need instructions on how to do this (although I believe it is as simple as filing a Trac ticket requesting a Trac component). We may want to discuss ways that students and teachers can report bugs without having to create a Trac username (which is, for some, a significant barrier to entry - not that it's difficult to make an account, but that there may be reluctance to create an account, particularly for children).
=== Have and pass a smoke test ===
=== Have and pass a smoke test ===
=== Add your own idea here ===
'''Rationale:''' We need a quick way to make sure the Activity works, so the Activity needs to define what it means for it to "work," and then come up with a straightforward set of instructions that anyone can use to demonstrate and/or verify that it is working.
'''Test:''' This should be fairly simple.
* Do you have a smoke test?
* Did you run it? (Can anyone else run it?)
* Did it pass? (Can you prove it?)
* Is there a place to file results? (Can people find them?)
'''Instructions:''' We need a guide on how to make a good smoke test. Sample Activity tests can be found at http://wiki.laptop.org/go/Test_cases_8.2.0#Activity-specific_test_cases, but they're old and there's no guidance on which are good tests or not.
=== Journal interaction works ===
'''Rationale:''' The Journal is one of the most interesting aspects of the Sugar platform and it really showcases what makes Sugar different.
'''Test:''' Test to make sure that the activity saves and resumes from the Journal.
'''Instructions:''' (1) Launch the activity. (2) Use the activity. (3) Close the activity. (4) Open the Journal entry associated with the activity. Did a preview image get created? (5) Resume the activity. Was the previous state of the activity restored?
=== Collaboration works ===
'''Rationale:''' Collaboration is one of the most interesting aspects of the Sugar platform and it really showcases what makes Sugar different.
'''Test:''' This only applies if the Activity supports collaboration; if the Activity explicitly states that it does ''not'' support collaboration, this test passes by default.
If the Activity does support collaboration (or doesn't say whether it does or not):
'''Rationale:''' Where does this requirement come from and why is it important?
* Make 2 SoaS thumbdrives and install the Activity being tested on both.
* Get 2 computers; boot an SoaS thumbdrive on each one. Ensure both computers are connected to the same Jabber server.
* Start the Activity on one of the sticks, and share it with Neighborhood. Ensure the other stick sees that shared Activity in Neighborhood.
* Have the 2nd stick join the 1st stick's Activity. Ensure you are able to do this.
* Have both sticks collaborate within the Activity (however it is designed to be played). Ensure you can see the right data during collaboration - in other words, does this ''seem'' like the right way for this particular activity to be multi-player?
* Have the 1st stick leave the Activity. Ensure that both sticks handle this (the originator leaving the activity) gracefully.
If all of the above tests pass, the Activity meets this criteria for inclusion.
'''Instructions:''' links to instructions on how Activity authors and maintainers can fulfill the requirement, if possible.
'''Instructions:''' TODO: Information on how to code collaboration functionality into an Activity needs to be linked from here. Alternatively, if you don't ''think'' an Activity supports collaboration ''yet,'' you should (1) mark it as "Does not yet support collaboration" somewhere on its wiki page, and (2) file a ticket for it under that Activity's component so that developers can add that functionality later on.