[sugar] Release Cycle - Responsibilities

[David Farning]

The third step in establishing a release cycle will be determining
responsibilities.  This will be the biggest challenge.

Assessment of areas to improve.  This is not meant as a slight on the
hard work any individuals at OLPC have done on Sugar.  I am amazed at
the overall progress you have made in a few short years.

1.  Division of labor.  The same developers and managers are responsible
for both deployment support and future development.

2.  Encapsulation.  A large number of people monitor _all_ mailing lists

3.  Trust and empowerment.  Transition from the more closed development
of OLPC to the open nature of Sugar Labs.
 
Process improvements.

5.  Separate OLPC deployment support developers from the Sugar Labs
development develops.  In the last cycle it appeared that developers and
managers split their time between support and developments.  As a
result, no one was able to gain much momentum on either goal. 

6.  Split the Sugar mailing list into .laptop and .sugarlabs hosts.
Splitting the list will help us split our focus into the
stability/support mindset required by the OLPC release manager and the
innovation/development mindset of Sugar Labs.  
   
7.  Sugar Labs has no direct employees.  The direction of the project is
controlled by the oversight board who is elected by the membership.
This has worked out very well for many projects.

Stakeholders affect the project's direction and speed of progress by
either directly contributing or indirectly engaging other to contribute
on their behalf.

8. Iterate.  Iterate.  Iterate.  As we adapt to the chalanges of the
open source development process, we need to leverage it's greatest
strength.  Steady, repeatable improvements.

A thought here is too offset the Sugar Labs release from the OLPC
release by a few months.  Using two months as an example, Sugar Labs
could go through two months sub-cycles of big changes-little changes-bug
fixes.  OLPC could match this development with
integrate-stabilize-release sub-cycles.  If we sync SL's bug fix period
with OLPC stablization period we can 'merge our trees' once per release
then branch off in our own directions.

thanks
dfarning