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:[email protected]] 
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

Reply via email to