[IAEP] maintenance

[Tomeu Vizoso]

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