[Sugar-devel] Sugar Digest 2009-08-11

[Walter Bender]

=== Sugar Digest ===

1. Daniel Drake started a deployment-centric thread
[http://lists.sugarlabs.org/archive/iaep/2009-August/007651.html]
about Sugar's direction and goals and the role that Sugar Labs should
be playing. Much of the discussion is a rehash of issues we have been
discussing since we began Sugar Labs one-year ago: how best should we
engage deployments and how best to allocate our limited resources. And
while it would be easy to simply refer to the list archives, it is
better to revisit the discussion because (1) we (and the Sugar
deployments) are in a very different place than we were a year ago;
and (2) there is some apparent confusion regarding roles and goals for
the Sugar Labs community.

What has changed? (1) we have demonstrated an adherence to a set of
core values that embrace freedom and openness; (2) we are to a large
extend hardware and distribution agnostic; (3) we are much farther
along the path towards a stable 1.0 release; (4) we have participation
from a much broader community, which includes many (vocal) teachers.

What has remained the same? (1) we still have inadequate feedback from
the field; (2) we have no funds to dedicate to remedying (1); (3) we
have more iterations on our design to go before it reaches maturity;
and (4) we have insufficient materials for teachers to help them
through these immature stages of our design.

One topic raised by Daniel is the role Sugar Labs should play in the
existing OLPC/Sugar deployments. These deployments represent the vast
majority of Sugar users. But there is a real disconnection between
these deployments and the Sugar Labs developer community. (IMHO, this
disconnect is not unique to Sugar.) Daniel recommends that we send
developers into the field, which sounds great, but has some practical
implications as well: it takes time and money. Alas, so far I have
been unsuccessful in raising money for building such bridges—my
biggest personal disappointment over the past 12 months—but I plan to
keep trying. I will put some of the onus on the deployments as well.
While some have invited in developers from the community, others are
not yet to the point where they see this as a priority. I sense a
change, but it is going to take time. Perhaps if we draw more
attention to efforts such as Paraguay Educa, which is very active in
directly discussing issues with the broader community, then others
will follow their example. I remain of the opinion that in order to
scale, community engagement has to be a pull from the deployments as
oppose to a push from Sugar Labs (or OLPC). Of course, we need to be
responsive to the pull—I think we have a good track record in that
regard. And our being more aggressive (pushy) may help as a catalyst.

In a related topic, it was questioned the degree to which we should be
investing energy into small deployments, e.g., the Sugar-on-a-Stick
pilot that Caroline Meeks and I had been running this summer. Should
we be exclusively concentrating on the large deployments? Obviously, I
am personally invested in supporting small deployments because I am of
the belief that we will be able to grow our community and user base
more robustly by opening Sugar up to anyone who wants to use it,
regardless of the scale of their efforts. My engagement in small
deployments has been primarily in order to focus on discovering the
various aspects of the current workflows that impede adoption in a
classroom scenario. Caroline has been focusing on those aspects of
workflow specific to Sugar on a Stick. Greg Smith has been doing a
great of job of documenting our trials. And as Dennis Daniels has
pointed out, we need to have more tutorial-like resources available to
teachers if we want more than the most patient to try it. These many
small efforts will pay off in the long term and much of what we have
learned this summer will impact the large deployments as well.

Another topic was in regard to the degree to which Sugar Labs should
be doing OS work. We are an upstream project and we are getting more
proficient at working with downstream efforts: the Fedora community
(which has taken on much of the heavy lifting associated with
supporting the OLPC hardware); the Debian community (thanks to the
patient tutelage of Jonas Smedegaard); openSUSE, etc. At the same
time, we need to take a leadership role on occasion, such as when we
embraced the fledgling efforts to create a Live USB image. (While
Sugar Labs has played a role in these efforts and tracks bugs related
to them, the work has been done downstream.) We simply cannot afford
to do the OS work ourselves and it would be counterproductive even if
we had the resources to do so.

It was asserted in the discussion that Sugar Labs is not focused on
the needs of teachers. It is certainly not true that Sugar Labs is
uninterested in the needs of teachers—we have had numerous discussions
about how to solicit their feedback. Some efforts, such as the Sur
list, have been productive. And one glorious example of our success is
the fact that teachers are beginning to make their own modifications
to Sugar and Sugar activities. Regarding modifications to the Sugar
workflow that facilitate its use in the classroom, the vector is
pointing in the right direction. It will take time.

Daniel questions our commitment to simplicity. That is a matter of
constance vigilance. Every project suffers from feature bloat over
time. Beyond simplicity, we need to be disciplined about asking
ourselves, "how does this impact learning?"

There are some circumstances where there might be an appearance of
indifference—when a problem is pushed downstream. For example, in the
recent discussion about making our Live USB images more robust in
light of the device being removed without shutdown, it is not clear,
other than trying to influence workflow, that there is much that Sugar
Labs can do about this problem. However, Sugar Labs developers have
been in discussions with the various distros about how they might
address the problem. Sugar is part of a ecosystem and one role our
community can play is to raise awareness throughout the ecosystem of
the needs of teachers.

There has also been a discussion about the merits of local labs.
Daniel argues that "by requiring deployments to do technical work,
you're *really* challenging them (and sometimes, excluding them)." But
I think this is a somewhat distorted view of what we mean by a local
lab. Local labs provide a local sense of ownership. Sugar Labs
"central" is the community itself, which would be responsible for
setting clear goals and maintaining any necessary infrastructure
needed by the project as a whole, while the regional labs would use
their own means to make Sugar relevant to their local communities,
including creating for-profit enterprises, which Sugar Labs central
cannot do. A local lab may:
* Adapt the technology and pedagogy to an area's culture and resources
(e.g, developing activities and content specific to a region);
* Help translate Sugar to the local language(s);
* Support Sugar deployments in area schools;
* Create a local community devoted to the Sugar Labs principles,
making Sugar more open and sustainable;
* Provide for communication,between the local communities and the
global Sugar Labs community;
* Develop Local content and software that can be used not only for
local purposes but also for the overall community; and
* Host, co-host or partner in the organization of conferences,
workshops, talks and meetings related to the use or development of
Sugar.

But it need not be doing technical work. Of course, it would be great
if over time, some of the technical load is picked up in the
deployments.

Thanks do Daniel for calling us out on these topics.

===Help wanted===

2. Chris Ball, Ben Schwartz, and Michael Stone have been working on a
collaborative arithmetic quiz
[http://activities.sugarlabs.org/addon/4204]. It makes extensive uses
Ben's "groupthink" collaboration module. They are soliciting feedback.

===In the community===

3. Gonzalo Odiard reported on a successful
[http://lists.laptop.org/pipermail/olpc-sur/2009-August/004099.html
Sugar Day Argentina on the Sur list.] Gonzalo also describes three new
activities: [http://190.0.162.1/godiard/sugar/Domino/6/Domino.xo], a
game where the pieces may have different mathematical operations or
concepts which need to match;
[http://190.0.162.1/godiard/sugar/Ecomundo.xo], an ecosystem in which
there is grass, rabbits and foxes that are born, eat, reproduce and
die; and [http://190.0.162.1/godiard/sugar/Elements/2/Elements.xo], a
proof-pof-concept of a Javascript activity.

===Sugar Labs===

4. Gary Martin has generated a SOM from the past week of discussion on
the IAEP mailing list (Please see [[:File:2009-August-1-7-som.jpg]]).
Gary has made a number of modifications to his algorithm. Please give
him feedback as well.

-walter
-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org