[IAEP] Unifying the Sugar Labs experience Was: [Sugar-devel] Project Guidelines posted

[David Farning]

> Isn't this related to Brainstorm and Blueprints in Launchpad?

Yes, I agree they are closely related.

I would like to take a step back and look at the problems we are
trying to solve.

Backstory.
Over the past couple of months I have spent most of my time working
with 'external' people and organizations.  I have been looking for
ways we can work together.  Originally, I though of the problem as how
do we Identify, Engage, and Empower potential contributors.  That is
pretty standard volunteer recruitment strategy.  This approach has
been creating a dissonance that I did not understand until Mel chewed
me out last night.

The dissonance is that identifying, engaging, and empowering potential
contributors flies in the face of nearly everything Sugar Labs stands
for.  The correct approach is to focus on creating a community culture
where potential contributors can discover what they want to do,
discover how to engage with the community, and discover how they can
implement their ideas. Identify, Engage, and Empower still holds true.
 Sugar Labs must be discoverable so new contributors can figure out
how they fit in.

Consistency and clarity of community.
In marketing we often talk about the importance of a clear and
consistent message.  The release cycle is premised around clear and
consistent dates for developers to converge and diverge.  The way to
make Sugar Labs discoverable is to create a clear and consistent
community.

Creating this consistency does not depend on long weighty legal tomes.
In fact, the opposite is true.  This consistency comes from clearly
sticking to a few guiding principles.  Following are three examples of
reoccurring situations that happen across the project.

#1
A few months ago we were discussing the the pros and cons of updating
Sugar via activities.sugarlabs.org.  Initially the discussion were
heated and rather handwavey.  Then the devteam implemented the 'new
feature' process.  Engaging in the new feature process shifted _all_
of my energy from _proving_ that update is a good idea to creating a
viable implementation.

The new feature process provided be a very good template for how to
proceed if I wanted my feature to be considered for the next release.
I filled out the form and hacked together reasonable proof of concept
code.  One day a core developer, aslroot, pickup the code and rewrote
it.  A few days later I got a email from Simon asking me to clean up
the release notes because it was going to included in .86.

The new process guidelines provided me, the inexperienced developer, a
way to align my work flow and expectations with the development team.

#2
Last Summer we work we several groups of students.  Jameson worked
with Mel and Leslie Hawthorn on the GSOC project.  Fred worked with
Prof. Steve Jacobs and I with the RIT co-op students.

Our experiences were very different.  At RIT we were flying blind. It
was the first time:
Anyone taught a course combining community service and technology
using open source and Sugar.
RIT made an exception to allow unpaid co-ops.
RIT allow remote co-op.

None of us had clear expectations.  Communications suffered.

GSOC is now in its 5th iteration.  They have very good guidelines for
how projects can effectually 'identify, engage, and empower' students.
Identify - via the project proposal.
Engage - via the mentor.
Empower - the student is free to explore, collaborate, and reflect
within the limits and expectation of the project.

#3
Recently the GSOC team brought in $4500. $2000 in travel money and
$2500 in general money.  The challenge was determining how to spend
it.  Rather than push this decision up to the oversight board we
appointed the GSOC mentors an ad hoc committee who had authority to
spend their money as they see fit.  The oversight board is in the
process of approving this via lazy consensus.

By creating a very light weight decision making body of GSOC mentors
we pushed the spending authority out to the people with who were
highly engaged in the GSOC project.

Themes
Life cycle guidelines --  The value of life cycle guidelines show up
across the project.  The new feature process does a very good job of
explaining how to take an idea for a new feature through to becoming
part of a release.  The process makes no judgment on the value of an
idea. Instead it aligns expectations of  the new developer and the
release team.

The GSOC guidelines are another variation on life cycle guidelines.
It focuses on best practices to help insure that students, mentors,
and projects all have matching expectations.

Delegating authority -- The oversight board and the ad hoc GSOC
spending committee are are both example of delegating authority
through lightweight decision making bodies.  It took less than ten
minutes to set up the committee and get board approval.  The decision
are being made by those most knowledgeable about the subject.

Future action items.
Project guidelines -- Project guidelines are just life cycle
guidelines for how top level project can fit into Sugar Labs.  The
specific problem they solve is forcing premature decisions about what
is good, bad, and useful.  A recent example of this has been the Qt
work Tomeu has been doing.

Student guidelines --  Student guidelines are just life cycle
guidelines for how student can immerse them selves in the community
and become effective contributors in a short period of time.

Engineering  steering committee -- The committee is just a delegation
of decision making authority down to the people who understand the
technical needs of the project.

Hope this helps explain some of the reoccurring situations which I am
working through.  Over the next couple of weeks, I will go through
these issues again.  This time presenting them as solutions to
reoccurring problems -- rather than list of things we should do.

david