10,579
edits
Changes
Jump to navigation
Jump to search
Line 7:
Line 7: − + − There are many ways to contribute to the triage effort: feedback from the Sugar users in field about priorities is especially important. Of course, we'd also like to hear from you if you'll have time to help with coding.+ − Please join us. + − 2. Stefan Unterhauser (dogi) has set up http://idea.sugarlabs.org as a place to capture ideas and discussions.+ + + + + + + + + − + + + + +
→What's new
===Sugar Digest===
===Sugar Digest===
1. Tomorrow (Monday, 1 March) is Triage Day for the next Sugar release: Sucrose 0.88. We'll be meeting on irc.freenode.net channel #sugar-meeting at 14UTC (9EST) to review the open tickets for the 0.88 milestone. We'll also look at tickets from previous milestones that have remain open. The goal is to prioritize tickets based on their severity and their impact on our learning mission; we will subsequently allocate resources to the most important tickets; the milestone on some tickets will be reassigned to 0.90.
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: Etoy, 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===
===In the community===
3. Deborah Nicholson of the Free Software Foundation asked me to pass along an announcement about LibrePlanet, a "free as in freedom" software conference. You can register at http://groups.fsf.org/wiki/LibrePlanet2010.
3. Things are moving quickly in Argentina. Gonzalo Odiard has been blogging about their progress in La Rioja at [http://godiard.blogspot.com/ 1] (Also see [http://www.idukay.edu.ar/dirprimaria/ 2])
===Sugar Labs===
4. Gary Martin has generated a SOM from the past week of discussion on the IAEP mailing list (Please see [[:File:2010-Feb-27-Mar-5-som.jpg|SOM]]).
=== Community News archive ===
=== Community News archive ===