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/[email protected]/msg06280.html On Tue, May 6, 2014 at 7:49 PM, <[email protected]> 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:[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 > > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
