10,574
edits
Changes
Jump to navigation
Jump to search
Line 7:
Line 7: − 1. 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.+ − 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. − 2. Chris Ball, Ben Schwartz, and Michael Stone have been working on a collaborative [http://activities.sugarlabs.org/addon/4204 arithmetic quiz]. It makes extensive uses Ben's "groupthink" collaboration module. They are soliciting feedback.+ − 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.+ + + + + + + − 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.+ + + + +
Sugar Labs/Current Events (view source)
Revision as of 18:02, 17 August 2009
, 18:02, 17 August 2009→What's new
=== Sugar Digest ===
=== Sugar Digest ===
"He was guided by what he saw rather than what he wanted to believe." – Vernor Vinge
1. While I am not chasing down Turtle Art bugs, I am catching up with my summer reading. The quote from ''A Fire in the Deep'' seems a nice summary of the discussion about teaching physics on the [http://lists.sugarlabs.org/archive/iaep/2009-August/007722.html IAEP list]. It is worthwhile reading the whole thread.
2. Some other summer reading includes a short article on behavioral economics published by the [New Economics Foundation neweconomics.org] that discusses some principles of behavior that we may want to consider was we consider how to maximize the impact of our efforts as a community. (I am unaware of any serious study of Free Software by behavioral economists. This particular summary is more useful in regard to understanding the motivation of teachers whom we'd like to consider adopting Sugar and perhaps become more observant about what they are doing with the platform in their classrooms.
I am thinkig about each of their principles as a vehicle for asking questions that I am hoping community members may be able to discuss.
* "Other people’s behaviour matters."
:This would suggest that we need to expose teachers to Sugar best practices that they can then emulate. Can we identify the "mavens", "connectors", and "salespeople" in our target communities? What resources can we apply to influence their adoption of Sugar? For example, I am working with a small school district in the Boston metropolitan area that other, larger districts follow closely. If we can have an influence with a "maven" district, we may get broad leverage. It also suggests that we need to be viligant as a community to make sure that our examples for emulation are pedagogically sound.
* "Habits are important."
:This would suggest that we raise awareness about some of the habits that are part and parcel with the status quo. What incentives can we provide that would encourage change? What actions can we take to sustain and reenforce changes in behavior?
* "People are motivated to ‘do the right thing’."
:We need to engage teachers in a discussion about what is "the right thing" and remind them that the right thing is often hard work: "Sire, there is no Royal Road to Geometry" – Euclid.
* "People’s self-expectations influence how they behave: they want their actions to be in line with their values and their commitments."
:This is a tough one for us, because much of what we are doing is not inline with expectations. However, we as long as we are on a sound footing in terms of values, we are in a position of influence.
* "People are loss-averse and hang on to what they consider ‘theirs’."
:Sugar need not be an either-or proposition. (Sugar on a Stick means there is nothing to give up in taking up Sugar.) And as Minsky has pointed out, until you understand something from more than one way, you don't understand it. Sugar can be offer another perspective on their status quo.
* "People are bad at computation when making decisions."
:Further, they are often intimidated by the prospects of learning new things (until they are actually doing it). "Immediate losses are stronger incentives than long-term rewards." This would imply that we really need to keep the "pain" associated with getting started to an absolute minimum.
* "People need to feel involved and effective to make a change."
:We have a community with a potential for great discourse that welcomes contributions. This is one of our real strengths."
===Help wanted===
===Help wanted===
3. Last week's discussion about feedback led to the suggestion that I highlight feedback from the field in the ''Sugar Digest''. Please send me reports that I can include each week.
===In the community===
===In the community===
4. There has been a lot of activity on our [http://getsatisfaction.com/sugarlabs "community-powered" support portal]. The interface is a bit clumsy, but much more friendly to non-developers than the [dev.sugarlabs.org trac] system. Check it out. (Dennis Daniels has been including links to screencasts with most of his posts.)
===tech talk===
5. In the run up to string freeze for Release 0.86, Simon Schampijer led a triage session (See [http://dev.sugarlabs.org/milestone/0.86 Milestone 0.86]).
6. Tom Gilliard (satellit) continues to experiment with alternative formats for Sugar LiveUSB images (See [http://people.sugarlabs.org/Tgillard/]).
===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-August-8-14-som.jpg|SOM]]).
===Just for fun==
Another quote from ''A Fire Upon the Deep'': "Finally they pulled the big, floppy ears simultaneously: the dataset popped open." Sounds like he was describing an OLPC XO-1.
=== Community News archive ===
=== Community News archive ===