accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: [VOTE] Accumulo Bylaws, vote 2
Date Fri, 04 Apr 2014 14:37:20 GMT
The majority approval vote on version 1 of the bylaws passes. Because of
the extensive discussion and vote changes, I will list each voter's final
vote below. Please verify that my list is correct based on the vote's
history prior to 1400 UTC (10 AM EDT / 7 AM PDT) today.

Sean: +1
Bill H: +1
Eric: +1
John: -1
Josh: +0
Christopher: -1
Mike: +0
Corey: +1
Brian: -0
Billie: -0

Totals:
+1: 4
+0: 2
-0: 2
-1: 2

I will update the bylaw doc to version 1 and remove the draft statement. I
will also fix the link that Sean found early on. Based on the vote history,
and if there is no objection, I will also add to the doc (replacing the
draft statement):

Community work actively continues on the bylaws, and so key segments of
them are subject to change.


Thank you to everyone who voiced their opinions and voted.

Bill H


On Fri, Apr 4, 2014 at 9:20 AM, Billie Rinaldi <billie.rinaldi@gmail.com>wrote:

> Changing my vote to -0.  I am personally neutral on whether we alter the
> document before changing its version number or vice versa, but there
> appears to be (informal) majority approval for fixing first.
>
> Regarding Christopher's comments, I think that using majority approval to
> vote to change to consensus approval is internally consistent -- the people
> who vote against believe in majority approval, so they should be okay with
> the vote passing.  It's the other direction that has problematic logic.
>
>
> On Thu, Apr 3, 2014 at 8:15 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > I don't know that the consensus vs. majority issue is fixable ex post
> > facto... by establishing these bylaws, we're basically binding
> > everybody in the community to a set of rules that is not in full
> > agreement (with majority approval). Binding those who disagree to the
> > rule that it is okay to proceed in spite of their disagreement seems a
> > bit authoritarian. I understand that the initial vote was following
> > the rules in the content of what was being voted on... and that makes
> > sense to me, and I agree with it. However, given my concerns about
> > binding dissenters to the same rules, with the sensible goal of using
> > the established rules for establishing those same rules, it seems to
> > me that full consensus is the only option that makes sense.
> >
> > If there were no other outstanding issues, I would say that we could
> > move past this and change to consensus for modifying bylaws later...
> > but then we're going to revisit this same chicken/egg problem then,
> > but in a weird way: we'd be using majority voting to change to
> > consensus voting. If there's minority dissent at that point, it'd
> > still pass, but only by enacting a rule that would not have passed had
> > the newly applied rule been in place. It seems to me that full
> > consensus for initiating or modifying bylaws is the only sensible and
> > internally consistent mechanism for voting on the bylaws themselves.
> >
> > The other issue, regarding clarification of wording around code
> > changes I think can be fixed later.
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Thu, Apr 3, 2014 at 8:14 PM, Sean Busbey <busbey+lists@cloudera.com>
> > wrote:
> > > Could the -1 voters please explain what we can't fix with a follow on
> > > modification to the bylaws after this vote?
> > >
> > > Even on the matter of consensus vs majority approval for bylaw
> > > modifications, it is relatively easy for a follow on vote to make this
> > > change. It is no more difficult, say, than starting another vote after
> > this
> > > one fails. Certainly, it is easier than the reverse transition would
> be.
> > >
> > > -Sean
> > >
> > > On Thu, Apr 3, 2014 at 6:43 PM, Mike Drob <madrob@cloudera.com> wrote:
> > >
> > >> Changing my vote to +0.
> > >>
> > >> While I think the bylaws are fine as is, and I think future issues can
> > be
> > >> fixed through follow on amendments, there are clearly issues that have
> > not
> > >> been resolved. I would like to see strong adoption for the first pass,
> > and
> > >> then majority for future issues.
> > >>
> > >>
> > >> On Thu, Apr 3, 2014 at 3:57 PM, Billie Rinaldi <
> > billie.rinaldi@gmail.com
> > >> >wrote:
> > >>
> > >> > On Thu, Apr 3, 2014 at 3:37 PM, Sean Busbey <
> > busbey+lists@cloudera.com
> > >> > >wrote:
> > >> >
> > >> > > On Thu, Apr 3, 2014 at 5:14 PM, Billie Rinaldi <
> > >> billie.rinaldi@gmail.com
> > >> > > >wrote:
> > >> > >
> > >> > > > On Thu, Apr 3, 2014 at 1:57 PM, Bill Havanki <
> > >> > bhavanki@clouderagovt.com
> > >> > > > >wrote:
> > >> > > >
> > >> > > >
> > >> > > > Going by the standards of a release vote, voting is actually
the
> > >> > > > appropriate time to discover fundamental issues.  That's
kind of
> > the
> > >> > > whole
> > >> > > > point of voting -- getting people to agree that there are
no
> > >> > fundamental
> > >> > > > issues with what you're voting on.  Finding valid, justifiable
> > issues
> > >> > > > should be welcome, as it results in a better product, whether
> the
> > >> > product
> > >> > > > be a release or a community standard.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > As an aside, this is not encouraged in our current release
> process.
> > >> > >
> > >> > > The test practices for a release take longer than the voting
> period
> > for
> > >> > an
> > >> > > RC. This directly implies that the fundamental issues must have
> been
> > >> > worked
> > >> > > out prior to a call to vote.
> > >> > >
> > >> >
> > >> > Our disagreement here might largely be due to differing definitions
> of
> > >> > "fundamental issues."  Also, I think you might be blocking out what
> > >> > happened between the first 1.5.0 release candidate and the last? 
=)
> > >> >
> > >> >
> > >> > >
> > >> > > I've been fine with this interpretation, largely because it lines
> up
> > >> with
> > >> > > Apache guidelines around votes: do the consensus building work
up
> > >> front.
> > >> > If
> > >> > > we're going to use a release vote as a time to do primary vetting,
> > then
> > >> > we
> > >> > > should probably change our RC vote window.
> > >> > >
> > >> >
> > >>
> >
>



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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message