[IAEP] SoaS as a Sugar Labs project.

Tomeu Vizoso tomeu at sugarlabs.org
Tue Aug 25 10:43:57 EDT 2009

On Tue, Aug 25, 2009 at 16:13, Bernie Innocenti<bernie at codewiz.org> wrote:
> El Mon, 24-08-2009 a las 20:58 +0200, Martin Langhoff escribió:
>> And also... and completely from the outside... I'll apologise in
>> advance for saying something I know might be controversial. I worry
>> that SL seems to have -- for a external party like me -- more
>> bureaucracy than it has people "doing". IMHExperience, the projects I
>> enjoy working on, and that I see being productive have  a much lower
>> "procedure/label/committe " : contributor ratio.
> I don't necessarily disagree with you, but just 2 days ago I was offered
> an advice on the other side of the spectrum by Michael: he notes that a
> lot of important things are falling through the cracks because nobody
> organizes the available resources.  His suggestion is to introduce real
> project management into the game, which is basically what David's
> Projects idea seems to bring.

I agree with that, though instead of Projects I was thinking of
feature champions to herd the cats that may be involved in getting the
feature completed. This job could be carried by anyone and would
consist on tracking the progress, documenting the need, bugging the
different people involved, etc.

> My initial reaction was that community projects work by employing
> maintainers rather than project managers.  The substantial difference
> between the two is that a maintainer does not proactively set priorities
> and allocate resources.  There was an hidden assumption in my thinking
> that a maintainer /could not/ tell people what to do based on the fact
> that his workers are unpaid volunteers.

I think a maintainer is just a maintainer and we shouldn't overload
the role. No problem with some people having a more leading role if
they have the energy and wish to do so.

> But, as Michael pointed out, besides the volunteers who are strongly
> self-motivated, there are also many others who are seeking for guidance
> and would actually feel confused by the fuzziness and apparent lack of
> direction of an organization with plenty of individual freedom.
> Some wasted effort happens when a volunteer looses focus or motivation
> along the way and nobody else takes over.  This is common even among
> highly successful communities such as the Linux kernel hackers.  The job
> of any half-skilled project manager would be detecting these stalls and
> mitigate them whenever possible.
> Hopefully, the formalization of our development efforts into
> well-defined entities called projects led by officially appointed
> project leaders will help rebalance things.

Hmm, not sure how this would work. Improving the reliability of the
sharing experience could be one of those "projects"?

>> Time for me to shut up. From now on I assume you know about these
>> risks, and won't mention the topic in polite company no more. After
>> all, I am not working my ass off on SL, you are.
>> Thanks for your patience :-)
> A meta-comment on your post: you don't need to apologize and be shy for
> offering your criticism, no matter how many people will disagree with
> you.  A culture of open criticism is essential for improving our
> processes, especially when a good advice comes along with the critical
> part.

As Bernie said, a constructive discussion is a positive contribution,
no need to apologize.

> I recently got useful criticism from Bemasc, Christoph and Daniel on
> #sugar regarding our relationship with Deployments.  Their feeling is
> that we didn't do enough to get them involved, mine is that our efforts
> to reach out have been largely unsuccessful for reasons I do not fully
> understand.  By discussing it through, it became apparent that we
> actually had in mind two fundamentally different things: I'm interested
> in getting *contribution* from deployments rather than offering them
> *support*.
> I now realized that the two things should go together and we probably
> shouldn't ask for contribution without offering some support in exchange
> for it.  This is the essence of participation, the antithesis of passive
> dependence, which would be unsustainable both for SL and for its
> deployments.

I agree with that.



«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David

More information about the IAEP mailing list