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.ben...@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-n...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/community-news > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel