accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: [DISCUSS] Majority voting without prior discussion
Date Wed, 07 May 2014 15:40:38 GMT
Here's a link to Benson's input during the bylaw adoption process, where he
discusses consensus and majority in the greater context of how ASF has
historically worked.

https://www.mail-archive.com/dev@accumulo.apache.org/msg06280.html



On Tue, May 6, 2014 at 7:49 PM, <dlmarion@comcast.net> wrote:

>
>  Your comments suggest that we need to tailor our model to follow the U.S.
> Senate. We will need a vote to end debate, so that we can vote on the
> measure. Can I filibuster? Just kidding, I wouldn't wish that on anyone.
>
>  In all seriousness, I agree with your statements. I did the same thing
> with the blog thread, discuss, gather feedback, vote on text that was
> agreed upon. I went back and looked at the bylaws, which specify majority
> approval for ending a planned release and for an official release. What if
> they were consensus approval instead? Or, maybe a modification to the
> bylaws that states certain types of votes cannot be started without a
> discussion first.
>
> -----Original Message-----
> From: Christopher [mailto:ctubbsii@apache.org]
> Sent: Tuesday, May 06, 2014 4:59 PM
> To: Accumulo Dev List
> Subject: [DISCUSS] Majority voting without prior discussion
>
> 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.
>
> 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.
>
> Thanks for your time and input.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>


-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

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