On Fri, Apr 30, 2010 at 1:29 PM, Walter Bender <walter.ben...@gmail.com> wrote: > 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.
I *do* care. While my sugar-core code-related action possibilities might be limited for now (though I'm hoping to improve that over the summer), I'll do everything possible to back such an effort from a Sugar on a Stick perspective. Thanks for bringing this up. It *is* an important conversation to have and I'm glad we're having it. --Sebastian > regards. > > -walter > > On Fri, Apr 30, 2010 at 6:38 AM, Tomeu Vizoso <to...@tomeuvizoso.net> 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!) >> IAEP@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/iaep >> > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > _______________________________________________ > IAEP -- It's An Education Project (not a laptop project!) > IAEP@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep