[DISCUSS] Majority voting without prior discussion

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

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

Re: [DISCUSS] Majority voting without prior discussion

[Keith Turner <ke...@deenlo.com>]

On Tue, May 6, 2014 at 4:58 PM, Christopher <ct...@apache.org> wrote:

> 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.
>


When considering something for which there is no prior precedent, we should
discuss it on the mailing before voting.  Part of the discussion should
probably be what kind of vote we should have.  If there is disagreement
about the vote type in discussion, a conservative resolution would be to
have a consensus vote.


>
> 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.
>

For the bylaws, it may be better to consider an entire life cycle all at
once instead of piece meal adding parts of the life cycle.

We have established a precedent with 1.4 and its archived in the mailing
list. Even if its not in the bylaws, this precedent should make EOL of 1.5
more efficient.


>
> Thanks for your time and input.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>

Re: [DISCUSS] Majority voting without prior discussion

[Billie Rinaldi <bi...@gmail.com>]

I definitely agree with #1.  Still pondering #2.


On Tue, May 6, 2014 at 1:58 PM, Christopher <ct...@apache.org> wrote:

> 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
>

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
>>

Re: [DISCUSS] Majority voting without prior discussion

[Billie Rinaldi <bi...@gmail.com>]

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
>

Re: [DISCUSS] Majority voting without prior discussion

[Sean Busbey <bu...@cloudera.com>]

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.

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

Re: [DISCUSS] Majority voting without prior discussion

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

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,  <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
>

Re: [DISCUSS] Majority voting without prior discussion

[Bill Havanki <bh...@clouderagovt.com>]

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/dev@accumulo.apache.org/msg06280.html



On Tue, May 6, 2014 at 7: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
>
>


-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

RE: [DISCUSS] Majority voting without prior discussion

[dl...@comcast.net]

 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