Re: Draft of Proposal for the GNOME Foundation.
- From: Maciej Stachowiak <mjs eazel com>
- To: Nat Friedman <nat helixcode com>
- Cc: foundation-list gnome org, rms gnu org
- Subject: Re: Draft of Proposal for the GNOME Foundation.
- Date: 13 Jul 2000 12:25:15 -0700
Some comments below.
Nat Friedman <firstname.lastname@example.org> 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
> 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.
> 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
> 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
] [Thread Prev