accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Majority voting without prior discussion
Date Wed, 07 May 2014 01:34:52 GMT
Releases should be majority, according to the ASF
(http://www.apache.org/dev/release.html#what). I'm also not concerned
about release plans/cancellations being majority, because those
inherently require discussion, and modification to a release plan
seems like it can be done pretty easily. Also, we've never really had
a formal release plan, so I'm still curious how that's going to play
out.

My main concern for this thread is things not enumerated explicitly
and whether or not we feel that majority approval can be appropriate
for those things, at least, without plenty of advance opportunity for
consensus gathering first. (And to a much lesser extent, formalizing a
sensible EOL policy for the future).

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


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
>

Mime
View raw message