Re: Planning releases

[Bart Decrem <bart eazel com>]

Havoc,

I think your latest set of proposals goes too far in weakening the power of the
board.  I believe that

1) the board or a releases committee should have as one of its roles release
coordination.  and of course in order to do an effective job at that, it will have
to work closely with all the hackers
2) 'recall elections' or other formal processes to undo board action or replace a
board (member) should be exceedingly rare (kind of like the right to fork).  So I
think the only type of member recourse should be to fire the board, as opposed to
give veto power over any specific decision.  Frankly, if members don't agree with
a decision or a release schedule, it won't get implemented anyway.
3) I do think the board should make decisions most of the time, as opposed to
issuing recommendations.

I think it's important that we not shy away from making decisions.  There needs to
be a group of people who are actually empowered to make decisions, and then those
folks should be accountable to the larger community.

As a practical matter, there'll be lots of consensus building, especially since
the power of the board as proposed is already extremely limited (it sets release
schedules and decides which modules are part of Gnome) - but I don't think we
should weaken those specific powers by softening the language of the board's
charter.

Bart



Havoc Pennington wrote:

> George <jirka@5z.com> writes:
> > Even if the board has power to make this decision, it first needs a
> > consensus by the maintainers of the different packages.  The release plans
> > are really in the hands of the maintainers.
> >
> > However perhaps having such a power is good.  Then the board has to either
> > derive it's decision from the maintainers, OR the board has to convince the
> > maintainers that it's decision is ok.  Even if it has power to make arbitrary
> > decisions about release dates, it has no way to truly enforce and implement
> > such arbitrary release dates.  But making this official board decision will
> > ensure that all major parties are well aware of the release plans (something
> > which was not exactly happening in the past).  So it's still consensus
> > driven, and most likely the decision process will be the same with the
> > difference that in the end the board "approves" the release plans.
> >
>
> Good point, I have no doubt that it will end up working this way in
> practice no matter what we actually write down in the bylaws.
>
> Perhaps we could say: "The board will be responsible for writing down
> and publicizing a proposed release plan, including schedules, content
> of the release, and parties responsible for managing the release. The
> board should create this plan by attempting to build a consensus among
> the membership, especially the maintainers of the core projects. The
> board will oversee the plan, and keep it up-to-date in the event of
> delays or changing circumstances."
>
> Or something, that's awfully vague. What happens if there's no consensus?
> (Is it even possible to release if there's not? I'm not sure it is,
> without forking some projects.)
>
> As a check, we could say that if X number of members request a
> referendum on the proposal, then there's a vote; if a majority are not
> in favor of the proposal, it becomes "rejected" and goes back to the
> drawing board. I suppose we could have this check on all board
> actions, not just release plans. Alternatively we could say that all
> major actions have to be approved by a vote (i.e. they are rejected by
> default, instead of accepted by default).
>
> I'm rambling I guess. But I like the idea that the board creates
> "recommendations" or "proposals". I think we should call them that
> instead of "decisions," just to keep everyone in the right spirit of
> consensus-building.
>
> Havoc
>
>
>
> _______________________________________________
> foundation-list mailing list
> foundation-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/foundation-list