Re: Draft of Proposal for the GNOME Foundation.

[Joe Shaw <joe helixcode com>]

> >        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.

I disagree. It goes against the whole open nature of the process. As long
as we have leadership (the Board and module maintainers), I see no reason
to disallow anyone who has contributed some code, docs, translations, or
art from having a vote. Flamewars on gnome-list aren't productive, I
agree, but when it comes down to a "Yea" or "Nay" vote, then it is. Not
that most of the people on gnome-list would be members anyway. I would say
that the gnome-devel-list population is a little more accurate.

> 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.

Why not? They're a contributor, they should have a vote.

> I don't think we should allow any referendums other than recall of the
> board.

Hmm. If we have a sufficiently large enough requirement for a referendum
(5%, 10%?), I see no reason to prevent the general membership from
overriding what a majority thinks is a bad idea.

> 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.

I agree. I think 9 is good, 11 at most at least initially.

> 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?

Nat and I discussed this, and here is our reasoning for it:

We really can't make a GNOME release without unanimous agreement from all
the project maintainers. If Jacob doesn't want to do a gnome-core release,
we really can't make him and he can sandbag and delay a release
indefinitely. There's simply nothing we can do about that.

Now, in the event that a module maintainer doesn't want to release, we
have a few choices. The first is that we kick that module out. We could do
this for stuff like gnome-media, etc. but it isn't possible for stuff like
gnome-core. Secondly, we can delay the release until the module maintainer
wants to do a release. Generally, if a module maintainer really -really-
doesn't want to do a release, he has a pretty good reason for it and it's
worth hearing. Lastly, we could fork it, but that's obviously very very
bad and let's not even talk about that.

> 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.

Huh? Most of the decisions that are made by a small group of people and
the Steering Committee will be made by the board like it is now. The
people who do releases (module maintainers and documentation and
translation coordinators) will still do the releases. The only real
changes are that now there is a defined body who makes these decisions and
that the people who are most involved in the project can have more of a
say in the specific decisions we make.

Joe