Sugar on a Stick/Activity Criteria: Difference between revisions

(19 intermediate revisions by 7 users not shown)

Line 1:

<~~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 ==

~~== 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]].

~~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~~.

The table of activities mapped against these criteria can be found at the [[Criteria_Status|wiki page]].

== 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 ===

Line 26:

Line 37:

* 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 ===

'''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?

: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?

: 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 ===

Line 74:

Line 95:

'''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 [[~~Talk:Sugar_on_a_Stick~~/~~Getting_Involved~~|this tutorial]]).

'''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).

Line 80:

Line 101:

=== 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.

~~Be sure to describe~~:

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.

~~'''Test:''' how we can make sure that~~ the ~~requirement is met - what sort of testing needs to be done to verify~~ this?

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.

@@ Line 1: / Line 1: @@
-<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 ==
-== 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]].
-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.
+The table of activities mapped against these criteria can be found at the [[Criteria_Status|wiki page]].
 == 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 ===
@@ Line 26: / Line 37: @@
 * 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 ===
 '''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?
+: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?
+: 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 ===
@@ Line 74: / Line 95: @@
 '''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 [[Talk:Sugar_on_a_Stick/Getting_Involved|this tutorial]]).
+'''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).
@@ Line 80: / Line 101: @@
 === 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.
-Be sure to describe:
+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.
-'''Test:''' how we can make sure that the requirement is met - what sort of testing needs to be done to verify this?
+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.