[sugar] Proposed Governance - was: (Re: [IAEP] Sugar Digest 2008-06-09)

[Jim Gettys]

> 2. Governance: One of the challenges that free and open-source
> projects face is the impact of governance on their community members:
> while FOSS licenses assure access to source code, that doesn't
> guarantee a successful project. A governance model can help ensure
> that the project is run in a professional, disciplined, and equitable
> manner. Good governance lets the community engage in discourse and
> provides a transparent mechanism for arbitration in the hopefully rare
> circumstances in which it is necessary.
> 
> Some attributes that are necessary for good governance include:
> meritocracy, transparency of process, open access to anyone who has
> demonstrated the skills to contribute, and a means to ensure a balance
> of control so that no one special interest wrests control of either
> the discourse or the decision-making.
> 
> A draft proposal for a governance model for Sugar Labs has been posted
> to the wiki (Please see
> http://wiki.sugarlabs.org/go/SugarLabs:Governance). Community input
> and feedback is important: please help us get this done properly. Feel
> free to make corrections and comments in the wiki or on the IAEP list.
> 

In general, I like what I see.  I think somewhat more (and somewhat
less) specific governance needs to be specified from what I see so far.

Not all of these need to be addressed in a temporary working governance
document, but do need to be addressed in permanent governance documents,
and those need to exist in finite time, and ratified by the membership.

Clearly, if we're to go the Software Freedom Conservancy route, some of
the legal boilerplate overhead one finds in documents such as the Gnome
Foundation bylaws Bylaws are not needed.
(http://foundation.gnome.org/about/bylaws.pdf).
But some other issues should be covered are not currently in the
governance document: for example:
	o how the governance document is modified; what determines quorum for
such actions
	o how decisions are appealed
	o how notice is given of decisions
	o how do we adopt permanent governance regulations; as these currently
are, they can at best be temporary until a membership exists and
ratifies a more formal governance document....
	o what to do about removing/recalling members/board members; it is the
board that matters most here).
	o how vacancies are filled
	o limits on board membership by employer
	o how money is disbursed.

Again, many of these issues don't matter when things are working well;
but if/when disputes arise, having mechanisms for fixing the problem in
advance removes much of the heat from the system. Establishing
procedures people find transparent and fair in the middle of controversy
is very difficult. 

Some particular critiques:

1) I don't think so many (or maybe any) committees need to be hard-wired
in the governance document, particularly at the current size of the
project.  Instead, I'd recommend making it clear that the oversight
board can form committees, and how they can be dissolved.  Using the
list that exists as examples of what sort of things are envisioned is
fine, of course.

In Gnome, for example, when I was serving on the board there was no
standing community committee; but each conference (organized by
different sets of people in different parts of the world) had its own
organizing committee that started up before the event, and ran somewhat
over; IIRC, the BOD in that case just selected the group holding Guadec
and got occasional reports of how the organization of the meeting was
proceeding, as part of the BOD oversight role.
 
We found in X.org that getting rid of committees that weren't doing
anything ?was a headache (along with the overhead we had in the bylaws
for choosing those committee members). We had an elected technical board
which ended up not doing anything; getting rid of it was a headache as
it was enshrined in the bylaws, which then had to be amended, which was
a PITA.

2) Specifying that meetings be "online" is a mistake; there will likely
be times that other sorts of meetings take place of the oversight board,
and you don't want to make that impossible.

3) The decision panel mechanism seems cumbersome, and fraught with
political danger; if people don't believe the oversight board is being
fair, they should get rid of the oversight board.  There is the
(possible) issue of how to evaluate technical decisions in dispute if
the board ends up less technical than many projects (which might in fact
be the long term outcome we'd like to see in Sugar).  

Some mechanism that permits the board to delegate decision authority (or
solicit advice) may be useful. It might just be the same committee
mechanism, if committees are easy to establish/de-establish.

In a (technical) meritocracy, often many of the people *best* able to
judge the technical merits of technical controversy end up serving on
the board, and I think it a mistake to forbid oversight board members
from serving on such committees.  In short, while there may be
circumstances where such a panel is needed, I suspect as currently
proposed, the decision panel being enshrined in governance is a mistake;
and we can use the general committee mechanism to handle the cases where
it may be needed.
                            - Jim

-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child