[IAEP] maintenance

[Sebastian Dziallas]

On Fri, Apr 30, 2010 at 1:29 PM, Walter Bender <walter.bender at 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 <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
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>