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

[David Farning]

On Mon, 2008-06-09 at 11:07 -0400, Jim Gettys wrote:

> 
> 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
> 
Walter, Jim
  I just looked at some other project's bylaws.  The eclipse bylaws(1)
cover a lot of the points raised by Jim. 

Thanks
Dfarning


1 http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003_11_10%
20Final.pdf