Re: [DISCUSS] Majority voting without prior discussion

[Christopher <ct...@apache.org>]

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
<bi...@gmail.com> wrote:
> On Wed, May 7, 2014 at 9:07 AM, Sean Busbey <bu...@cloudera.com> 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, <dl...@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
>> >
>> >
>>
>>
>> --
>> Sean
>>