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

[Sean DALY]

IMHO, close study of small deployments makes them incredibly useful to
all teachers and Learners. The observations and take-aways need to be
triaged of course, starting with what can/should be done by Sugar
Labs, but I am convinced many learnings will benefit large
deployments. Until reliable means of sharing experiences and feedback
(polls, questionnaires, council of deployers, etc.) can be put in
place, microscopic study of a classroom using Sugar is well worth the
effort, in particular for revealing blockers.

Sean.


On Tue, Aug 11, 2009 at 4:18 PM, Walter Bender<walter.bender at gmail.com> wrote:
> === 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
> _______________________________________________
> Community-news mailing list
> Community-news at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/community-news
>