The discussion about pedagogy on the IAEP list intensified this week. My takeaway from the discussion is that while we won't (and don't need to) reach consensus about "one right way" to teach, we must have consensus around our goals as a community or our efforts will become too diffuse to be of any practical use; we are not engaged in an academic exercise—we are touching the lives of real children on a global scale. Indeed, the primary reason we spun One Laptop per Child from MIT (and Sugar Labs from One Laptop per Child) is because we intend to deliver "things to think with" to learners everywhere.
As a community, we have consensus that Sugar and Sugar activities should be freely and readily available to learners everywhere. This would suggest that the developer community continues to strive to make it “simple” to create and share Sugar activities and its efforts to create versions of Sugar that run on multiple operating systems and on multiple hardware platforms.
But what is Sugar? At one level, Sugar is an API that provides a unified framework for activity developers to support collaboration, reflection, and sharing in their programs. But those features were chosen with a purpose: to encourage learners to engage in authentic problem-solving and a critical dialogue about whatever problem in which they are engaged. Thus engaged, learners will develop skills that help them in all aspects of life.
Sometimes that dialog is with your peers, sometimes it is with a teacher or mentor. Sometimes it is open-ended and sometimes it is within the context of structured instruction. In every case, it involves expressing, debugging, critiquing, and reflecting. In every case, it is enhanced by "the hard things to learn", Alan Kay's "non-universals", e.g., reading and writing; deductive abstract mathematics; model-based science; etc.
The culture of FLOSS, with its emphasis on en plein air debugging and critique, is part of our pedagogy. Sugar embodies the message that everyone has an opportunity and responsibility to contribute to our knowledge commons. That contribution need not be Python code. Members of the Sugar community must:
- explore, share, evaluate, and debate best practices;
- provide technical and pedagogical support; and
- create new learning activities and pedagogical practice.
Roland Gesthuizen, replying in a different thread, had a concrete set of suggestions for teacher participation in our community:
- report back issues that make using the Sugar interface difficult when used it in the classroom (collaborate)
- develop and share lessons built around applications that work on Sugar (curriculum)
- share by word of mouth, blog and twitter with colleagues that we are using Sugar (communication)
- ask deep and hard questions about the learning that goes on when students use Sugar (pedagogy)
- work to answer these questions (research)
- and more...
In the run up to the next Beta release of Sugar on a Stick Sebastian Dziallas has asked for help with testing all of the activities being considered for inclusion. We'd like to be more thorough in finding any problems so that we can be sure to address them in time for the final release in September/October. There is also a Trac query that pulls up all of the open tickets for SoaS.
In the community
The OLPC France Sugar Camp meeting will be held in Paris on May 16.
There will also be a Sugar meeting on the 17th (See Paris Sugar meeting).
A team of Babson College management students will be working with Sugar Labs beginning this fall as part of a Management Consulting Field Experience (MCFE) Program.
Christian Schmidt led a Design Team meeting this weekend that covered topics such as improvements to the Home View, a clock extension on the Frame; support for printing within Sugar; a global strategy for keyboard shortcuts; and a global dictionary.
Gary Martin has generated a SOM from the past week of discussion on the IAEP mailing list (Please see SOM). It is worth a close look this week.