Tomeu, Thank you for writing down this summary and for making a proposal as to how we can address this problem. I would add that the problem reaches farther than the core Sugar modules themselves: Sugar without Sugar Activities is not very useful to the learner. We need to maintain a core set of activities as well.
I agree that getting the deployment team revived is critical to any solution. regards. -walter On Fri, Apr 30, 2010 at 6:38 AM, Tomeu Vizoso <[email protected]> wrote: > Hi, > > follows a plan about how to improve the situation regarding > maintenance of our software modules. If you care about it, please > reply even if only to say so, or even better, comment on it and > suggest improvements. I will assume that lack of replies mean people > don't care about it and will stop caring about it myself. > > == The problem == > > The process by which our software reaches to children is complex and > involves several organizations. Sugar Labs is one of those and its > responsibility is to provide the raw sources that organizations > "downstream" such as OLPC, Fedora and Paraguay Educa will modify, > package, ship and install. It's very important that modifications done > downstream are kept to a minimum so that all downstreams share as much > work as possible. This means that the raw sources we provide need to > contain the features that downstream need in each release and that it > contains as few bugs as possible. > > In order to provide good "raw sources", we have a series of processes > that assure that the expected features are present and that the worst > bugs are either fixed or at least well-known. These processes include > testing, bug triage (keeping the bug database in order), source > release, code review, user experience design and code development. An > important role present in most of those processes is that of the > module maintainer. > > A module maintainer takes responsibility for a part of the source > code. The maintainer will release code at known times and will have > worked so it has gone through the processes outlined above. Of course, > the maintainer cannot do all the work by herself, but is ultimately > responsible for it. Normally the maintainer will have spent most of > her time triaging and fixing bugs, and will be trying hard to keep the > module "in order" so that in future releases the maintenance burden > doesn't grow too much as new code gets in. An important process in > keeping the maintenance burden in check is "code review", by which the > maintainer checks that the new code that gets in a release won't > increase the maintenance burden too much. > > The problem is that very few people in Sugar Labs are willing to do > that maintenance work. We have people keen on packaging Sugar, > deploying it, training teachers on it, developing new activities and > new Sugar features, people write books about Sugar, setup help lines > to support Sugar users, universities are given grants to study the use > of Sugar, load machines with it, etc. Big amounts of volunteer time > and money are being spent around Sugar but almost nothing is going to > maintenance. Paradoxically, any use of Sugar requires that it is > reasonably stable and most investments are made with the assumption > that Sugar will keep being developed. > > I also want to make explicit that almost all maintenance effort has > come from a few volunteers that are tired and disappointed about the > little importance that has been given to this work. We are very close > to have no maintainers at all in Sugar, meaning as well that nobody > with the needed experience will be around to mentor new maintainers. > > > == Proposal A: Get downstreams working better inside Sugar Labs == > > I would say that the main reason why so many people are keen in > investing on Sugar but so little goes into maintenance is > miscommunication. Downstreams don't know how Sugar is developed, who > develops it nor what is to gain by investing upstream nor what they > risk by not doing so. And we cannot keep sitting on our hands waiting > for each of them to have an epiphany. > > I don't want to give the impression that nobody is doing any of that > outreach work, Walter has met with OLPC deployment representatives and > has tried to explain it to them, Bernie is volunteering at Paraguay, > Gonzalo is working at the OLPC deployment in Argentina and I have > traveled to Uruguay to talk about this. But while these individual > efforts have had a positive effect by themselves, we still have lots > of other downstreams to reach and we also must follow up on those > relationships. My hypothesis is that we are losing great opportunities > by not having better covered this area. > > In order to do that, I think SLs should give maximum priority to > revive the deployment team: > http://wiki.sugarlabs.org/go/Deployment_Team > > > == Proposal B: Get our community thinking about resourcing == > > If the deployment team was working as it should (with participation of > several downstreams), the needs of our users and partners would be > voiced there. But it's not enough with voicing needs, it can even be > harmful if we make exigences on overworked volunteers because some > will burnout and stop contributing. We also need to think about how we > can get the resources to address those needs. > > A community team would be working on improving Sugar Labs' community > of doing things. They would be making sure that SLs is a good place > for downstreams to work together on Sugar and also a good place for > volunteers to give their time and skills. > > Again, some individuals have been doing pieces of this, but my other > hypothesis is that we need a coordinated effort. I find very > disappointing that almost zero conversations are held about how to > resource what we want to happen. > > > == A concrete plan == > > So I have voiced needs, but how are we going to resource them? > > First step is to create the teams and keep them alive. Doing so takes > very little time if we stick to the minimum required. A team can be > considered alive if it has a coordinator, a members list, regular > meetings, a to-do list and an updated mission statement. I estimate > that this can take the coordinator less than 10 hours per month. > > Of course, some team coordinators will also want to lead the team with > a stronger effort commitment and will be proposing strategies, > starting discussions, inviting members, etc. But that's something that > is not strictly required for starting a team. If the team is kept > alive, people will come and things will start to happen. > > So in order to get started, we need to find 2 individuals who care > enough about Sugar to devote to it 10 hours per month of their time. > It's also ok if the team's first item in the TODO list is to find a > new coordinator, no need for a long term commitment. > > Regards, > > Tomeu > _______________________________________________ > IAEP -- It's An Education Project (not a laptop project!) > [email protected] > http://lists.sugarlabs.org/listinfo/iaep > -- Walter Bender Sugar Labs http://www.sugarlabs.org _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
