Talk:Activity Team: Difference between revisions

(5 intermediate revisions by 4 users not shown)

Line 1:

==Help Wanted list?==

Would it make sense to have a page where we list desired features to existing activities too? For example, I've got a number of tweaks to Turtle Art that either have been requested from the field or that I would like to make, but if someone is willing to tackle some of them, all the better. --[[User:Walter|Walter]] 12:58, 11 January 2009 (UTC)

: You got it, we just have to decide whether it's best to have activity requests on the main TODO list or on sub-pages. Right now I'm leaning towards the main TODO list, I want to impress people with how much work there is to do :) [[User:Wade|Wade]] 19:52, 12 January 2009 (UTC)

: Requests moved. [[User:Wade|Wade]] 21:00, 12 January 2009 (UTC)

==~~=Turtle Art help wanted=~~==

==Inclusion criteria==

* move the ~~show/hide blocks~~, ~~erase~~, ~~and stop buttons~~ to the ~~toolbar~~

There have been discussion of inclusion criteria over the years: i.e., which activities should be included in a Sugar distribution? I stumbled across this old post from October 2007 that still seems relevant. --[[User:Walter|Walter]] 22:04, 13 January 2010 (UTC)

* add run and step buttons to the ~~same toolbar~~

* reconfigure audio initialization so that it ~~only happens when TA starts up~~ or ~~gets sent~~ to the ~~background~~

15. Core activities: There has been a discussion on the devel list

* don't let bricks get lost off the ~~screen~~

about the criteria for inclusion of core activities on the laptop.

* add a ~~special stack "hat" for "main"~~ (~~tied~~ to the ~~run button above~~)

We'd like to broaden the discussion. Some proposed "Criteria for

Inclusion":

A. Epistemological impact—to what degree does this activity positively

impact learning? (This is of course the most important criteria.)

B. Fun—is it fun? engaging?

C. Quality—is the activity sufficiently robust in its implementation

that it will not compromise the integrity or supportability of the

system? Is the overall quality of the implementation adequate to meet

our standards? Can the community be engaged in the process of testing

and "certifying" and maintaining the activity?

D.Sugarized—to what extent has the activity been integrated into

Sugar, including UI, Journal, security, internationalization, etc.?

Does the activity require the folding in of additional libraries and

resources? (This has impact on robustness—positive and

negative—support, bloat, and the overall usability, aesthetics, and

perception of quality of the machine.)

E. FOSS—is the activity and all of its dependencies free and open?

F. Extensible—is the activity something the community can extend? Does

it span multiple needs? (And does it have—or the potential of

having—an upstream community of support?)

G. Uniqueness—does the activity add a unique feature to the core?

H. Expectations—does the activity meet the expectations of (children,

teachers, parents, G1G1 audience, etc.)?

I. Discoverable—is the core activity discoverable? (This is not to say

that it shouldn't be hard work to fully exploit the power of an

activity, but it should have a low barrier to entry.)

@@ Line 1: / Line 1: @@
 ==Help Wanted list?==
 Would it make sense to have a page where we list desired features to existing activities too? For example, I've got a number of tweaks to Turtle Art that either have been requested from the field or that I would like to make, but if someone is willing to tackle some of them, all the better. --[[User:Walter|Walter]] 12:58, 11 January 2009 (UTC)
+: You got it, we just have to decide whether it's best to have activity requests on the main TODO list or on sub-pages.  Right now I'm leaning towards the main TODO list, I want to impress people with how much work there is to do :)  [[User:Wade|Wade]] 19:52, 12 January 2009 (UTC)
+: Requests moved. [[User:Wade|Wade]] 21:00, 12 January 2009 (UTC)
-===Turtle Art help wanted===
+==Inclusion criteria==
-* move the show/hide blocks, erase, and stop buttons to the toolbar
+There have been discussion of inclusion criteria over the years: i.e., which activities should be included in a Sugar distribution? I stumbled across this old post from October 2007 that still seems relevant. --[[User:Walter|Walter]] 22:04, 13 January 2010 (UTC)
-* add run and step buttons to the same toolbar
-* reconfigure audio initialization so that it only happens when TA starts up or gets sent to the background
+. Core activities: There has been a discussion on the devel list
-* don't let bricks get lost off the screen
+about the criteria for inclusion of core activities on the laptop.
-* add a special stack "hat" for "main" (tied to the run button above)
+We'd like to broaden the discussion. Some proposed "Criteria for
+Inclusion":
+A. Epistemological impact—to what degree does this activity positively
+impact learning? (This is of course the most important criteria.)
+B. Fun—is it fun? engaging?
+C. Quality—is the activity sufficiently robust in its implementation
+that it will not compromise the integrity or supportability of the
+system? Is the overall quality of the implementation adequate to meet
+our standards? Can the community be engaged in the process of testing
+and "certifying" and maintaining the activity?
+D.Sugarized—to what extent has the activity been integrated into
+Sugar, including UI, Journal, security, internationalization, etc.?
+Does the activity require the folding in of additional libraries and
+resources? (This has impact on robustness—positive and
+negative—support, bloat, and the overall usability, aesthetics, and
+perception of quality of the machine.)
+E. FOSS—is the activity and all of its dependencies free and open?
+F. Extensible—is the activity something the community can extend? Does
+it span multiple needs? (And does it have—or the potential of
+having—an upstream community of support?)
+G. Uniqueness—does the activity add a unique feature to the core?
+H. Expectations—does the activity meet the expectations of (children,
+teachers, parents, G1G1 audience, etc.)?
+I. Discoverable—is the core activity discoverable? (This is not to say
+that it shouldn't be hard work to fully exploit the power of an
+activity, but it should have a low barrier to entry.)