Archive/Current Events/2010-03-17

Sugar Digest

1. activities.sugarlabs.org (ASLO) has been the subject of much discussion of the past few weeks. One thread has been in regard to making ASLO a place where not only Sugar developers upload their activities, but where Sugar learners upload the media objects that they create with Sugar activities. For example, a place for children to upload and share their Turtle Art projects or Physics simulations. A second thread has been in regard to whether or not to allow activities to be uploaded onto ASLO that contain non-Sugar dependencies. An example might be an architecture-specific binary file that is included in a .xo bundle or simply a dependence on a library that is not part of the core Sugar distribution. The arguments for such restrictions have to do with robustness and user experience. We don't want users to download activities that subsequently don't run, either because of an architecture mis-match or a missing dependency. We also want to be very careful about automatically pulling in dependencies because bandwidth and local storage are extremely limited for many Sugar users. However, from the beginning, Sugar has accommodated activities with dependencies external to the Sugar core: Etoys, Write, and Browse being three examples. And with the growth of the netbook market and innovations such as Sugar on a Stick, it is inevitable that Sugar users will be using a wide variety of architectures. (For example, OLPC is exploring the use of ARM processors in their laptops.) And, while we want to provide a consistent and substantial learning experience within Sugar itself, the extent to which we can be inclusive of other learning activities gives Sugar users the ability to reach further than they would otherwise. None of this suggests that we are abandoning the idea of a learning platform that provides a collection of affordances to the learner, such as the Journal, collaboration, and view source; Sugar (Sucrose and Fructose) is mostly written in Python with a consistent user experience across all of its activities; but our learning community should not have artificial walls and ceiling.

In a post that ties the two threads together, Ben Schwartz wrote:

If Sugar is working as intended, 99% of Activities will be crap. This is because the purpose of Sugar is to invite novices to engage actively in software development. Novices make bad stuff, and we want to install and run that stuff.

Or put another way, we want our learners to engage in creating and debugging, sharing their creations and engaging in a dialog about their creations. Developers learn by doing and so do children. ASLO is not just a portal for developers, it is a portal for learners.

Aleksey Lim (alsroot) solicited a policy statement from SLOB regarding the hosting of activity bundles with non-Sugar dependencies on activities.sugarlabs.org.

The Sugar Oversight Board passed a motion that: (1) Bundles with non-Sugar dependencies be clearly marked in ASLO; (2) We work towards a mechanism for supporting access to non-Sugar dependencies—a specific endorsement of being open; and (3) We do not restrict ASLO while we progress towards #2.

Mel Chua raised the question of support. I argued that this was a question orthogonal to architecture and dependencies, but that we clearly should make it clear to our user community that certain activities are supported. We'll be discussing the details at our next meeting.

2. We are pulling together our Google Summer of Code proposal and will be looking for mentors from the community. If you are interested in being a mentor, please contact Tim McNamara (timclicks on IRC; paperless AT timmcnamara DOT co DOT nz).

In the community

3. Things are moving quickly in Argentina. Gonzalo Odiard has been blogging about their progress in La Rioja at 1 (Also see 2)

Sugar Labs

4. Gary Martin has generated a SOM from the past week of discussion on the IAEP mailing list (Please see SOM).