Changes

This page is updated each week (usually on Monday morning) with notes from the Sugar Labs community. (The digest is also sent to the community-news at sugarlabs.org list and blogged at [http://walterbender.org/ walterbender.org].) If you would like to contribute, please send email to [[User:walter|walter]] at sugarlabs.org by the weekend. (Also visit <span class="plainlinks">[http://planet.sugarlabs.org planet.sugarlabs.org].</span>)

This page is updated each week (usually on Monday morning) with notes from the Sugar Labs community. (The digest is also sent to the community-news at sugarlabs.org list and blogged at [http://walterbender.org/ walterbender.org].) If you would like to contribute, please send email to [[User:walter|walter]] at sugarlabs.org by the weekend. (Also visit <span class="plainlinks">[http://planet.sugarlabs.org planet.sugarlabs.org].</span>)

===Sugar Digest===

=== Sugar Digest ===

1. As Caroline Meeks and I are wrapping up the Sugar-on-a-Stick summer programs, it has been a time to reflect upon what we have learned and what challenges face us in September (Many thanks to Greg, Anurag, Jennifer, et al. for their help). The goal of our pilots was to identify any issues we might face with a school-wide rollout of Sugar on a Stick and to work through many unknowns regarding the logistics of deployment.

Daniel Drake started a [http://lists.sugarlabs.org/archive/iaep/2009-August/007651.html deployment-centric thread] 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.

We learned a great deal, e.g., replication of custom keys: be sure to remove any owner keys in the .sugar/default directory before copying. And we experimented with a number of different workflows regarding how to prepare for a class: use USB extension cables if possible; preload helper boot CDs; have the children turn on their computers and then gather for a discussion of the lesson plan while the machines are booting; have a cache of hot spares since some USB devices inevitably will not boot (more on this in a moment); have the children shutdown the computers and then gather for a wrap-up discussion while the machines power off; etc. And we uncovered some bugs in our sharing logic (See my post from last week); and experienced some issues regarding robustness of the USB images.  

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.

It is this latter topic that was the subject of much debate on the Sugar mailing lists this week and which I would like to touch upon today.

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

While we did experience some "failures", given the circumstances, we were not able to do a very systemic analysis of the situation. We know that some sticks fail to boot and some have corrupted user data. We don't have an actionable characterization of the circumstances under which these problems occur.

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.

James Cameron summed up the situation:

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.

:If any state is preserved by the children on the USB sticks, and there is no copy of the state kept elsewhere, and there is a possibility of power failure, premature removal, or other interruptions, then every software component that uses the saved state must be either capable of detecting corruption of the saved state, or graceful recovery from apparently invalid state.

Meeting this challenge is not trivial; the more clarity we can bring to the use cases, the more likely we will be able to engineer solutions.

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 tutorlige of Jonas Smedegaard); openSUSE, etc. At the same time, we need to take a leadership role on occasion, such as when we embraced the fledgeling 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.

In the meanwhile, we need to: experiment with more USB manufacturers; be more careful about characterizing the different failure modes; do some workflow experiments to see if we can minimize failures; try different file formats; and come up with simple and robust backup/restore mechanism so that we can end run failures.

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.  

Greg Dekoenigsberg has suggested we take advantage of [https://fedoraproject.org/wiki/QA/Fedora_12_test_days Fedora Test Days] to put a more rigorous analysis together. But we need a testing plan which means we need to first come to consensus on what it is we are trying to test.

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

* Which Sugar-on-a-Stick image is being tested?

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

* What customizations have been made?

* Adapt the technology and pedagogy to an area's culture and resources (e.g, developing activities and content specific to a region);

* What process was used to create the USB device?

* What size and brand of device is being tested?

* Support Sugar deployments in area schools;

* What hardware the device is being tested on?

* Create a local community devoted to the Sugar Labs principles, making Sugar more open and sustainable;

* What is the nature of the failure? (no boot, corrupted data, etc.?)

* Provide for communication,between the local communities and the global Sugar Labs community;

* What was the history of use prior to failure?

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

Let's get a plan together and take advantage of this generous offer from the Fedora community.

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.

3. It is not too late to sign up as a [[Sugar_Labs/Governance/Oversight_Board/2009-2010-candidates|candidate]] for the Sugar Oversight Board. Also, please add yourself to the [[Sugar_Labs/Initial_Members_List|Membership List]] if you are not already listed.

http://activities.sugarlabs.org/downloads/latest/4204/addon-4204-latest.xo

http://activities.sugarlabs.org/addon/4204

===In the community===

===In the community===

4. Werner Westermann reported that "Patricio Acevedo left the audience shocked after [http://prezi.com/139914/ presenting Sugar] in the 2nd Innovation Workshop: The Creative Teacher, held in the Metropolitan Educational University, in Santiago, Chile." It was the first official activity of the newly formed Sugar Labs Chile.

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 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 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 Elements.xo], a proof-pof-concept of a Javascript activity.

 

5. [http://squeakland.org/squeakfest/usa/schedule/ Squeakfest USA] is next week in Los Angeles.

 

 

6. Sebastian Dziallas announced the availability of a new [http://download.sugarlabs.org/soas/snapshots/3/SoaS3-200908021950.iso SoaS snapshot] that includes the latest Sugar Release 0.85.3. It is a developer release--any testing would be greatly appreciated.

===Sugar Labs===

===Sugar Labs===

7. Gary Martin has generated a SOM from the past week of discussion on the IAEP mailing list (Please see [[:File:2009-July-25-31-som.jpg|SOM]]).  

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|SOM]]). Gary has made a number of modifications to his algorithm. Please give him feedback as well.

=== Community News archive ===

=== Community News archive ===