[IAEP] [Sugar-devel] Sugar Digest 2010-10-26

[Aleksey Lim]

On Wed, Oct 27, 2010 at 12:32:09PM +0000, Aleksey Lim wrote:
> On Tue, Oct 26, 2010 at 05:10:30PM -0400, Walter Bender wrote:
> > ==Sugar Digest==
> > 
> > 1. Tomeu's departure from the project has set off a lot of
> > introspection, speculation, 'blunt' emails, and thoughtful responses.
> > There is no doubt that we will miss Tomeu. He has been not just a
> > prolific contributor to the project, but also a steady hand, with the
> > professional's eye. Under his leadership, we have been able to raise
> > the quality of Sugar and we are much better integrated into the work
> > flows both upstream and downstream from Sugar. We must ensure that
> > this level of professionalism is not diminished.
> > 
> > The occasion of Tomeu's departure has triggered the voicing of many
> > unrelated frustrations with Sugar and Sugar Labs. Yioryos
> > Asprobounitis posted a thoughtful email
> > [http://lists.sugarlabs.org/archive/sugar-devel/2010-October/028319.html]
> > to the Sugar Developer list. In it, he reminded us of those things
> > that every successful project needs:
> 
> > * Clearly defined aims
> > * Clearly defined road map
> > * Clearly defined tools/methods of implementation
> > * Clearly defined, tangible, milestones and annual _external_ evaluation
> 
> Just my two cents..
> 
> Being absolutely agree with Walter,
> in my mind it can be concentrated in shorter statement (maybe someone
> already made it):
> 
> The main issue comes with major misunderstanding. For some
> participants Sugar is a particular software product (OS on an XO or even
> window manager with applications designed especially for it). Other
> participants think about Sugar as a subset of FOSS community. [Subset
> of] FOSS community can't have clearly defined aims and road maps except
> "Lets make this world better" (or so) and can't have clearly defined
> tools.
> 
> At the same time a particular parts of Sugar ecosystem are concrete
> software products (OLPC, SoaS, Dextrose and any Sugar deployment) with
> related functionality like clearly defined aims, road maps,
> implementation and QA.
> 

> What we really lack (as Walter said) is an architect [team?] that will
> plan/declare/try-to-follow long running coordination of Sugar ecosystem
err..  will declare low-level playing rules and do not try to plan
particular implementation. Intstead, it should create everythinhg to let
ecosystem to create [many] particular implementations.

> and took part in communication between Sugar-product-providers and the
> rest of Sugar ecosystem.
> 
> > While I think that the Sugar Community has worked hard towards
> > providing clarity, there remain deficiencies and disagreements.
> > 
> > Personally, my aims for are unwavering: Sugar is a software platform
> > that is designed for children for learning. Sugar is developed and
> > maintained by Sugar Labs, a global volunteer community of software
> > developers and educators. Our goal is to raise a generation of
> > critical thinkers and problem-solvers by establishing a culture of
> > independent thinking and learning. Through Sugar, we strive to provide
> > every child with the opportunity to learn learning within a context
> > that will allow them both to engage in an on-going critical dialog
> > with others and to develop independent means towards their personal
> > goals.
> > 
> > The technical underpinnings of Sugar are deliberately designed
> > maximize the probability that children will learn. Through the
> > Sugar-platform affordances, we encourage learners to explore by dig
> > deeply into topics for which they are passionate, to express by
> > building upon what they discover, and to reflect by engaging in
> > peer-to-peer and personal criticism. Free Software is fundamental to
> > the project not just as a means to an end, but also because of its
> > culture: it is no coincidence that Free Software developers don't just
> > write code; they talk about Free Software, they criticize it, and they
> > discuss other people's criticisms.
> > 
> > Regarding road maps, in my opinion we are quite disciplined in terms
> > of our day-to-day release process. However we are lacking a long-term
> > road map, which I would equate to an architectural specification. Such
> > a document could serve as a metric that would help us with some of our
> > short-term decisions and also help shape the project going forward.
> > 
> > Regarding tools and methods of implementation, while there has been
> > lots of heated discussion, I don't think we are so far apart in our
> > opinions. The seemingly endless debate about git vs email vs trac for
> > patch review is winding down. And we are getting better as a community
> > in showing patience with our handling of the influx of patches and
> > questions from newbies. Perhaps the best evidence that we are not so
> > far off track is the great job that has been done packaging Sugar
> > downstream by various organizations and deployments. We are producing
> > a product that they can work with and want to work with. Of course
> > there is always room for improvement and no doubt the debate about
> > tools and process will continue. That said, one legacy of Tomeu is to
> > be uncompromising on quality. I have submitted many patches and have
> > had very few accepted. But I have gotten thoughtful feedback and
> > learned a great deal in the process. My subsequent patches are better
> > for the effort of the Sugar maintainers.
> > 
> > Regarding tangible milestones and evaluation, I give us a mixed
> > review. We have a reasonable mechanisms in place for our release
> > process and we are cultivating ever-increasing feedback from the Sugar
> > deployments. However, we are lacking clarity around our long-range
> > technical goals. In terms of evaluation, Sugar in the context of
> > deployments is undergoing some level of scrutiny. There are on-going
> > evaluations underway in all of the major deployments. But with few
> > exceptions it is not clear how Sugar itself is being evaluating in the
> > field. We have some active testing teams, but we have not provided
> > them with very good tool chains; we have almost no automated data
> > collection to inform us as to how children are using Sugar. These
> > deficiencies are mitigated in part by an increasingly vocal community
> > of teachers and mentors and facilitators. Ultimately I think we will
> > learn more from our user community than is typical of other software
> > projects. Indeed, the fact that two teachers are running for positions
> > on our Oversight Board is really encouraging.
> > 
> > Dave Neary wrote a blog post about Ubuntu's plans to move to Unity as
> > the default desktop in which he mentions Sugar.
> > 
> > > OLPC had many teething problems with the Sugar desktop environment. Bugs, stability and performance issues plagued the project for many months, to the point where they abandoned the development of the stack as the primary target platform for the devices. The project lives on in Sugar Labs, thanks to a broad and vibrant developer community.
> > >
> > > There is not one out-and-out success story of a company building a great high-quality custom user interface on the standard Linux stack, except Android, which is hardly a model of collaborative software development.
> > >
> > [snip]
> > >
> > > There is another possibility which seems to me more plausible: building a rock solid and functional desktop is hard. Really hard.
> > 
> > What we are doing is hard. But it is also worthwhile. For those of you
> > who have never had a chance to visit a Sugar deployment, I urge you to
> > do so. What you will see, despite all of the shortcomings, is children
> > learning. That is why we are doing this.
> 
> -- 
> Aleksey

-- 
Aleksey