[IAEP] maintenance

[Tomeu Vizoso]

On Fri, Apr 30, 2010 at 19:31, Christoph Derndorfer
<e0425826 at student.tuwien.ac.at> wrote:
> Tomeu,
>
> thanks a lot for your message which indeed served as a strong reminder
> about the challenges in this area.
>
> Unfortunately I can't really provide any quick and actionable proposals
> that go beyond your proposal or Walter's comments.
>
> The only thing I would urge is for anyone who interacts with or works at
> deployments to emphasize this "help us to help you" point that you
> mention in your message. What I believe to have learned over the past
> year or so is that while many deployments actually have significant
> resources (both in terms of finances and manpower) at their disposal it
> can be incredibly hard if not impossible to justify (to donors,
> governments, etc) spending them on something that isn't very obviously
> and directly related to their work. Hence it doesn't come as too much of
> a surprise that things such as "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." are more commonly being worked on.
>
> One other aspect - and I debated awhile about whether to bring this up
> here - is that I think that for many deployments Sugar has reached the
> point where what they have is "good enough". Yes, some places will have
> strong desires for one particular feature or another and dedicate
> resources to it (e.g. 3G support for Uruguay). And we can all quickly
> think of a great number of features that we'd like to see added or
> improved upon. However in the grand scheme of things it seems like
> people are quite happy with what they have today and/or are currently
> more focused on the wealth of other challenges that deployments face on
> a daily basis(and there's plenty of those!). This point was really
> driven home for me when I asked Oscar Becerra of OLPC Peru about their
> software upgrade strategy in late February. His reply was along the
> lines of "What software upgrade? We're not even close to fully utilizing
> what we have right now [6xx builds in most cases]".

I agree in general with what you wrote, but I think the situation is a
bit more complex than that. If you talk to the top responsible for a
deployment, you are more likely to hear a call for focusing on
stability. If you talk to the head of pedagogy in that deployment, you
may hear about more activities more closely aligned with the
curriculum. If you talk to the responsible for support, you may hear
about a more stable journal with better provisions for deleting the
entries that take more place. If you talk to the responsible of
development, you may get a balanced view between a few new features
and more stability. Etc.

At the end, I think that we cannot get wrong if we assume that
downstreams generally want a project with continuity, with an adequate
progression in stability and new features and with a development
process that gives them some control.

As an aside, as much as a deployment would like to stick to an older
release, it's just not possible to do so without having to support
several versions simultaneously because new hardware often doesn't
support older software versions. I don't really think that any
deployment wants to have to support several versions very different
from each other.

> So maybe, just maybe, what needs to happen is for Sugar Labs and
> everyone involved to partially redefine what it is that Sugar Labs
> should be doing. This could go into several directions:

Totally agreed. If downstreams talked to each other about Sugar, they
would be able to give a very strong signal about where SLs should
head. That's the point of the deployment team.

> * make Sugar Labs the place where the cutting edge stuff in terms of
> advancement of the platform happens (with maintenance of older stuff
> suffering and being taken on by mature deployments)
> * make Sugar Labs a slightly more conservative place in terms of feature
> additions but a strong focus on stability and maintainability and
> support of deployments
> * stay on the current course which is a mixture of the above (and
> currently seems to hit its limitations)
> * try and go for what Ubuntu is doing with some sort of alternation
> between the progressive and conservation development cycles
>
> Maybe that last approach is something that's worthwhile discussing. I
> remember some exchanges ahwhile ago about changing the development
> cycles to be slightly slower and what some perceive as more suited to
> how many deployments work. This might also make life for developers and
> maintainers easier and entice more people to step up and support Sugar
> development and maintenance.

As far as I know, all these possibilities are on the table, we just
miss the appropriate people to join us around it.

Regards,

Tomeu

> Cheers,
> Christoph
>
> Am 30.04.2010 12:38, schrieb 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
>> _______________________________________________
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>
> --
> Christoph Derndorfer
> co-editor, olpcnews
> url: www.olpcnews.com
> e-mail: christoph at olpcnews.com
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>