Unfortunately, this thread dropped off my radar for awhile, due to the ASF email hiccups and such, but I wanted to just quickly revisit and close out the discussion.
>From this discussion, I think we don't really need to take any action to formalize anything further (I'm not going to initiate a bylaw change vote at this point). However, as a take-away, I do think it would be a good idea to encourage more consensus gathering, especially prior to majority votes, where vetoes don't exist. And, for that reason, majority votes should be used with reservedly, after a good faith effort to discuss. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 13, 2014 at 10:48 AM, Billie Rinaldi <[email protected]> wrote: > On Wed, May 7, 2014 at 9:07 AM, Sean Busbey <[email protected]> wrote: > >> We should not require an explicit discussion period prior to a majority >> vote, especially in our bylaws. Discussion and conflict resolution should >> happen as a part of our normal community interactions. If these things are >> not already happening, a mandated warm up period isn't going to fix >> that. Procedures are no substitute for community. >> > > Discussion is already mentioned in our governance docs: "Before calling a > vote it is important to ensure that the community is given time to discuss > the upcoming vote. This will be done by posting an email to the list > indicating the intention to call a vote and the options available. By the > time a vote is called there should already be consensus in the > community<http://accumulo.apache.org/governance/consensusBuilding.html>. > The vote itself is, normally, a formality." ( > http://accumulo.apache.org/governance/voting.html) > > Apache community is built around mailing list discussion, so it's hard for > me to see this as procedure over community. Certainly discussion is more > important for some issues than others. I personally was surprised by the > 1.4 eol vote being called without prior discussion -- in my opinion, this > was clearly something that warranted a discussion prior to a vote. Sean, I > think you did a good job of salvaging the situation, and I agree that we > should be prepared to handle new concerns expressed during votes, but I > also think we can usually do better than salvaging. > >> >> >> Generally, vote callers should have an easier time if they try to lead a >> discussion period first. Certainly if there isn't consensus over the >> fundamental matter of the vote, a DISCUSS thread is preferable to using a >> VOTE thread for discussion. >> >> However, there's no way to ensure that all concerns get hashed out prior to >> a vote. It is the responsibility of each person who votes to make a good >> faith effort. For those against that means explaining their concerns and >> how they can be met, especially during consensus votes. For those who are >> for the proposition it means attempting to address the concerns of those >> against and they must be particularly mindful in majority votes. >> >> While reflecting on how to phrase this message, I kept coming back to the >> ASF reasoning on voting[1]: >> >> > Reasons for Votes >> > >> > People tend to avoid conflict and thrash around looking for something to >> substitute - somebody in >> > charge, a rule, a process, stagnation. None of these tend to be very good >> substitutes for doing the hard >> > work of resolving the conflict. >> >> If more discussion is needed or modifications to the proposal are >> necessary, we always have the option of failing the vote and trying again. >> There's no need to add rules to draw the vote out either though altering >> vote periods or mandating a discussion period. It should be sufficient for >> concerned individuals to include the need in their vote of -1. A well >> functioning community should be looking for consensus. If you can't get >> enough people to join in on voting for more discussion, that discussion >> isn't likely to result in consensus. >> >> I would like to see us gain more rigor around sunsetting major releases. I >> don't think adding an additional vote type is the way to go about that. >> Instead, I'd like to see the discussion around how we're going to handle >> things in 2.0.0+ include setting up the whole lifecycle for major release >> development around release planning. >> >> -Sean >> >> [1]: http://www.apache.org/foundation/voting.html >> >> >> On Tue, May 6, 2014 at 6: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 >> > >> > >> >> >> -- >> Sean >>
