accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Majority voting without prior discussion
Date Wed, 07 May 2014 14:11:34 GMT
On Tue, May 6, 2014 at 4:58 PM, Christopher <ctubbsii@apache.org> wrote:

> Devs,
>
> As something that came out of the vote thread about EOL'ing 1.4, I was
> thinking:
>
> The purpose of a majority vote seems to be when we've already
> discussed and planned, and we just need things to come down to a final
> vote. Things like releasing, for example, occur after discussions,
> planning, and aren't a surprise in any way. It seems to me that there
> are two main points I want to make:
>
> 1) Prior discussion/planning should be a prerequisite for things which
> are majority vote.
> 2) The default for any ambiguous or arbitrary vote item that does not
> fall into a predetermined type, should require consensus.
>


When considering something for which there is no prior precedent, we should
discuss it on the mailing before voting.  Part of the discussion should
probably be what kind of vote we should have.  If there is disagreement
about the vote type in discussion, a conservative resolution would be to
have a consensus vote.


>
> The problem with majority votes without discussion is that there may
> be serious concerns a minority of persons voting have about something,
> that could be resolved with compromise.... where there is plenty of
> room for gathering consensus. Coming together as a community to move
> forward with a mutually agreed upon path should always be preferred
> where possible. In some cases, differences are irreconcilable and
> action just needs to be taken to move forward (releasing, for
> instance) on a majority decision, but even here, there is up front
> discussion about those differences (code development, release
> planning, etc.) prior to such a vote.
>
> Binding actions to a majority vote that has insufficient prior
> discussion, especially when there is no mechanism to extend a vote, or
> sane way to alter the contents of the majority vote while in progress,
> leads to actions that don't have the consensus of the community, even
> in circumstances where consensus was possible to achieve.
>
> I think our bylaws should be updated to reflect the two ideas above.
> I'm not sure the exact wording needed *(please submit proposals in
> response to this), but I think it should declare that any voting that
> does not clearly fall into a vote category explicitly enumerated, or
> if there's any doubt, should default to consensus. Before we had
> bylaws, this appeared to be the precedent... as we often took great
> care to respond to any objections, delaying, canceling, or extending
> the vote to do so. We should continue to operate with that same sense
> of community in future decisions as well, and I think consensus voting
> whenever possible is the way to do that.
>
> It was also discussed that it may be helpful to enumerate end of life
> procedures in the bylaws as well. I'm not sure this is as important of
> an issue if we agree that the default should be consensus... but I'm
> willing to entertain that discussion in this thread as well.
>

For the bylaws, it may be better to consider an entire life cycle all at
once instead of piece meal adding parts of the life cycle.

We have established a precedent with 1.4 and its archived in the mailing
list. Even if its not in the bylaws, this precedent should make EOL of 1.5
more efficient.


>
> Thanks for your time and input.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message