[IAEP] maintenance

[Walter Bender]

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 <tomeu at 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 at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org