Difference between revisions of "Archive/Current Events/2009-02-24"
m (moved Sugar Labs/Current Events/Archive/2009-02-24 to Walter is a wanker 9/Current Events/Archive/2009-02-24: Walter is a wanker)
m (moved Walter is a wanker 9/Current Events/Archive/2009-02-24 to Sugar Labs/Current Events/Archive/2009-02-24 over redirect: revert)
Revision as of 21:42, 23 February 2010
1. Kathleen A. Madigan, the founder of the American Board for Certification of Teacher Excellence, wrote a polarizing opinion piece in the Boston Globe this weekend (“A repackaged education proposal”, Opinion, Feb. 14) Madigan demonstrates that she values what she can measure rather than measure what she values. It is of course no surprise that a Hirschian, “standards-based reform" will lead to higher scores on standardized tests. But while Madigan assets that higher scores are a “success", she does not present any supporting evidence that there is a correlation between standardized test scores and achievement in the “real world.” In fact, many universities are dropping standardized tests from their admissions requirements precisely because they find little correlation between high scores and high achievement. Madigan's characterization of Darling-Hammond's “critical thinking and problem-solving” approach as antithetical to “academic content” and “specificity” is unsubstantiated. Undoubtedly, having basic facts readily at hand—on the "low shelf”—is important, but how you use those facts is equally as important. We can achieve and measure such a balance. A portfolio assessment that measures the whole child will tell us more about our children, their teachers, and our schools and closing the “knowledge gap” through authentic problem-solving can keep learning relevant. Further, since much of life in “the real world” outside of the classroom involves wrestling with open-ended problems, re-instating the arts—for which there seems to be no part in a Madigan standards-based school—should be part of any reform package that aspires to develop life-skills in our children.
2. Several different discussion threads this week have prompted me to write about the relationship between Sugar Labs and free software.
A question arose during a discussion about Sugar on a Stick (SoaS): Is SoaS a product of Sugar Labs? While it is an important part of our strategy to get Sugar into hands of more children, it is on par with other such efforts, such as Sugar on Fedora or Sugar on Debian. Sugar Labs “central” exists as a forum for the community to reach consensus on its goals. The heavy lifting is happening in the leaves, both upstream with those packaging the GNU/Linux distributions and downstream with those packaging Sugar for deployment on specific hardware or doing a Sugar deployment. Our product is the support of those efforts.
An article on OLPC News posed the question: Is free software better when written just by volunteers? The motivation for asking the question was a remark by Nicholas Negroponte, “Almost all the cutbacks were in engineering staff related to the in-house support of Sugar, which is far better done in the community. In fact, paying people to do it from within created a degree of control that was unsuitable for real open-source development.” While the premise from which this question is being posed is itself flawed (only a small fraction of the OLPC engineering staff had ever been working on Sugar) the real confusion lies in a more fundamental misunderstanding. Apparently it cannot be said too often: ”Free as in speech, not as in beer.” The power of free software (software libre) is that it can be “used, studied, and modified without restriction.” There is a residual in that it enables the community to play an important role in development, but it does not directly follow that all development can be done entirely by a volunteer effort. The professional resources that Red Hat made available during the development of Sugar were necessary in the creation of Sugar and the development of Sugar ”products” will require dedicated in-kind contributions from industry and from the organizations doing major deployments.
One essential role played by the community is that of critic (what Mr. Negroponte describes as counterproductive in-fighting). But it is anything but counterproductive—it is one of our great strengths. While we have had our differences, we have learned from each other and Sugar is the better for it.
Community jams, meet-ups, and meetings
3. There will be a Family XO Mesh Meetup on Saturday, February 21st, 2009, 10 AM to 1 PM at Gallaudet University, Washington, D.C. 20002.
4. Michael Stone reported on some ”awesome” deployment meetings (See Feb 03 deployment meeting minutes and [http://wiki.laptop.org/go/Deployment_meetings/20090210 Feb 10 deployment meeting minutes).
5. Minutes from the Friday the 13th meeting of the Sugar Labs oversight board are posted in the wiki.
6. Simon Schampijer and the release team would appreciate more feedback regarding the upcoming Sugar Release 0.84 (See the Triage Guide). Also, Tomeu Vizoso is trying to organizing more direct feedback for 0.86 would like to propose the next Sugar release (0.86). He is proposing that one point person be designated in each deployment area to be the point of contact between the global and the local Sugar communities. This person would ”coordinate tasks where direct communication between individuals is not practical” (See deployment feedback).
7. OLPC will not be issuing a major software release this spring (9.1), but is proceeding with an update to last fall's 8.2 release. Chris Ball has announced ”the first in a series of signed candidate builds leading up to the release of 8.2.1.” For those of you using XO laptops, the 8.2.1 release team would appreciate your help testing (See 8.2.1 preparation).
8. Christian Schmidt is looking for pictures from projects children and teachers have created with Sugar to use as illustrations for the new Sugar Labs website.
10. Simon, Tomeu, and Marco (Presenti Gritti) have been busy pushing out new releases:
11. Gary Martin has generated another SOM from the past week of discussion on the IAEP mailing list (Please see SOM).