Re: Draft of Proposal for the GNOME Foundation.

[Maciej Stachowiak <mjs eazel com>]

Some comments below.

Nat Friedman <nat@helixcode.com> writes:

>        In the past, being a part of the GNOME project has simply meant
>        "I wrote  some code" or "I hang  out  on the mailing  lists and
>        build the  thing  from  CVS  frenetically every  three  hours."
>        There is no reason to change this.

Yes there is. Can you honestly say that having a debate on gnome-list
is a useful decision-making process?

Anyway, I think more than not capturing the consensus, the idea that
anyone who wants to should have a voice in decision-making is pretty
opposite to most opinions expressed so far.

>     Releasing GNOME, defining GNOME
>     -------------------------------
> 
>         The foundation bears  the responsibility  of coordinating each
>         subsequent  release  of GNOME.   For  each release,  this will
>         include setting a schedule  (whether or not it is overlooked),
>         choosing the  set of modules which  are a part of the release,
>         and preparing the appropriate marketing materials.
> 
>         GNOME is a  loose   collection of independent  projects.   The
>         foundation will determine the set  of modules which fall under
>         the GNOME umbrella.  The foundation  will be able to endorse a
>         project  as  a  GNOME project  simply  by including    it in a
>         release.    In this way,    the  foundation will be  "defining
>         GNOME."
> 
>         It should be apparent that these two tasks (defining GNOME and
>         doing releases) are  deeply  interrelated: defining GNOME   is
>         just determining  which   modules are a   part of  any   given
>         release.  You can't  coordinate a release without knowing what
>         you're  releasing.  The set of  packages which comprises GNOME
>         is defined at  every   release.  And so releasing    GNOME and
>         defining GNOME are one and the same task.

Does that mean that no module is part of GNOME until it becomes part
of a GNOME release (and that therefore people working on it are not
per se working on GNOME)?
 
> II. Basic Structure and Operation of the Foundation
> 
>   The foundation will be a  virtual global entity, represented for the
>   purposes of funds  disbursement   in  many countries.  The     GNOME
>   foundation is divided into three bodies: the General Membership, the
>   Board of Directors,  and the Organizational  Forum  (Yeah, the names
>   are a bit corny.  Suggestions welcome.).

"virtual global entity" == "no actual legal existence"?

>   General Membership
>   ------------------
> 
>     The General Membership will be a large body made  up of people who
>     have made a contribution  to any  module which  is part  of GNOME.
>     The intent of the General Membership is to provide the opportunity
>     for all  contributors to have  a place  and  a voice in  the GNOME
>     foundation.  The General Membership will be open to all people who
>     want to be a member, and who have made any kind of contribution to
>     any part   of the GNOME  project,  with no membership  fee, and no
>     requirement of organizational or corporate affiliation.
> 
>     The general   membership will have two  responsibilities: electing
>     and deposing  members  of  the  Board of  Directors,  and  issuing
>     popular  referenda   on any issue  under   the jurisdiction of the
>     foundation, at any time (hopefully an infrequent event).
> 
>     The General Membership will be open to all people who want to be a
>     member, and who have made any kind of  contribution to any part of
>     the GNOME project.

I don't think "any contribution" is the right place to set the
threshold. When I get a 5-line patch I don't want to have to worry
about whether I'm giving that person full GNOME voting priveleges
automatically if I check it in.


>     Miguel will be the chairman and will preside  over all meetings of
>     the  board, unless he  is declared legally  insane and  "fit to be
>     tied" by the UN or the Pope.

I hate to appear to speak against Miguel (since he's the reason we're
here more than anyone else) but I think this clause is lame system
design. We didn't make George Washington President for Life.

> 
>   Referendum
>   ----------
> 
>     A   referendum   can be   issued by    any member  of  the general
>     membership.  An  electronic   voting system   will be  established
>     online, with members voting on a web page or by email.  The voting
>     system  will  maintain   a database  of   all  members   and their
>     passwords/public keys.
>   
>     In order for a referendum  to pass, 1/3rd  of the total membership
>     must  participate, and 2/3rds   of the participating members  must
>     approve.  There will be a mailing list for all of the members, and
>     all  referenda   must be announced  to the   list by the initiator
>     before they are opened on the voting system.   At least three days
>     must pass before  the referendum is closed,  and no referendum can
>     remain open for  longer than seven  days.  [ These numbers are, of
>     course, eminently debatable. ]

I don't think we should allow any referendums other than recall of the
board.
 
>   Elections and Board Size
>   ------------------------
> 
>     Elections for the board of directors will  be regularly held every
>     year.  Members will  run  as a slate,  to ensure  that the various
>     parts of  the project have equal  representation on the board.  No
>     slate may be  proposed which violates  any board constraints (such
>     as majority control by a single corporation).
> 
>     The  General Membership   will periodically  vote  for  new  board
>     members, when   one board member  resigns,  is dethroned or  a new
>     board seat is allocated.
> 
>     Election of a board members and slates  will be executed just like
>     voting on a referendum.
> 
>     The size of the board will scale with the number of modules in the
>     project.  The ratio (or whether or not this makes sense at all) is
>     an open question.

The board becomes completely non-useful past a certain size. Better to
declare a particular size range and let the membership decide if a
particular slate is the right size in that range.
     
> V. Release Engineering / Defining GNOME
> 
>   The  board of directors   will  be responsible for   authorizing the
>   release of a new version of GNOME.  The board will determine the set
>   of  modules which will  make  up the release   at  least 60 days  in
>   advance of the  release date, subject  to unanimous  approval of the
>   module maintainers.

Requiring unanimous approval for anything is not good. Setting fixed
date limits is also not good, this should be up to the judgement of
the board and the release coordinators (what if we decided to have
releases 30 days apart)? Also writing stuff like this into the bylaws
might make trouble later. For example, if we wanted to drop a module
from the release, would that mean we'd have to delay is 60 days?


In addition to the specific objections, I don't think this proposal is
very much in the spirit of even the very rough consensus we do have
now.

 - Maciej