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 Thu, 03 Apr 2014 22:39:33 GMT
<opinion owner="billh" validity="possibly_more_dubious">
I disagree that a limited-time vote is an appropriate time to find a
fundamental issue in what's being voted on. The effort leading up to the
vote should have been well-known, and if you care, you should be involved
then, doing your own assessments and working with others, having ample time
to do so. Sure, sometimes, a truly horrible, unforeseen problem can surface
after all that work. When that happens, everyone should vote against so the
vote fails. You would hope that is rare, though.

The time to forge agreement is before the vote, in deliberations, so the
product voted upon is the fruit of that. With this bylaw effort, sadly, I
observe that more attention is being paid to the bylaw effort at vote time
and not before, so I suppose my viewpoint isn't widely shared. (Sorry,
harshness warning.) It would, however, explain how this process is so
difficult now.

I don't see where we are misusing or misdefining "veto" in the bylaws. We
did, during deliberations, work to harmonize the bylaws with ASF standards,
e.g., eliminating undefined approval types like 2/3 majority, better
defining PMC responsibilities, getting emeritus status and access removal
standards right. I don't recall any problem with veto being raised.
</opinion>

Now as vote caller (to all):

If the bylaws in their current state are so unacceptable to you that you
would not be comfortable with them passing, then you should definitely vote
-1, especially as opposed to a +0 or -0. The current tally is +5 to -2, so
it is defeated by +1 voters switching, and/or others voting -1.

Also, if you haven't voted yet ... VOTE!

I will state just once more that the bylaws provide for amending, so
passage of this vote does not obstruct improvements, corrections, and
clarifications afterwards.

My tank is empty, and I've written way too much, so I bow out of this
discussion until the vote closes.


On Thu, Apr 3, 2014 at 6:14 PM, Billie Rinaldi <billie.rinaldi@gmail.com>wrote:

> On Thu, Apr 3, 2014 at 1:57 PM, Bill Havanki <bhavanki@clouderagovt.com
> >wrote:
>
> > <opinion owner="bill_h" validity="dubious">
> > Voting is not a substitute for deliberation, working as a group to
> generate
> > agreement on decisions. First, those involved get together and hash out
> the
> > details, and then at some point there is a vote on the outcome of those
> > deliberations. (Unless you're Congress. ZING) Deliberation can take a
> long
> > time ... a really long time. And it's not usually fun. At some point you
> > just must call it.
> >
> > I don't like consensus approval for bylaw changes because someone could
> > torpedo the vote and ruin the extensive work that went into getting
> there.
> > It can actually discourage being involved in the deliberative process,
> > because you could always just jump in at the vote time and veto, either
> for
> > a well thought-out reason or just because. That's not fair to everyone
> who
> > spent lots of time deliberating, compromising, exploring. (Harshness
> > warning.) If you really had an issue, you should have brought it up
> before
> > the vote was called so the community could spend proper time on it.
> Voting
> > time isn't the appropriate time to discover fundamental issues with what
> > you're voting on.
> >
>
> 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.
>
> Given that we already have a couple of departures from ASF definitions in
> our proposed bylaws, I think changing bylaws votes to Consensus Approval
> would be more in line with our community practices.  In particular, I would
> not feel good about the current vote passing, despite the fact that at the
> moment it meets the criteria of Majority Approval.
>
>
> >
> > Also, in life, you don't always get what you want, and you don't always
> get
> > it perfect the first time. Majority approval lets a group get something
> > good enough, even with some problems and disagreement, started, or
> > progressing. You can then begin a new round of deliberations, and vote on
> > modifications to make it even better.
> >
> > Even if that modification is changing to consensus approval for bylaw
> > changes.
> > </opinion>
> >
> > If the XML tag wasn't signal enough, this is really my opinion. Part of
> > this is working out, as a community, how we make decisions, so you should
> > certainly form your own opinion and apply it to the current vote and
> future
> > ones.
> >
> >
> > On Thu, Apr 3, 2014 at 4:29 PM, Mike Drob <madrob@cloudera.com> wrote:
> >
> > > bhavanki: can you expand on why you didn't like consensus approval for
> > the
> > > bylaws?
> > >
> > >
> > > On Thu, Apr 3, 2014 at 1:13 PM, Bill Havanki <
> bhavanki@clouderagovt.com
> > > >wrote:
> > >
> > > > I dug into the dev archives for how the approval definition got set.
> > > > Originally, from the ZooKeeper bylaws [1], modification required 2/3
> > > > majority of ALL PMC members to +1 in order to pass. Billie didn't
> > prefer
> > > > that since it isn't an ASF-defined vote, and suggested consensus [2]
> > > > (February 26).
> > > >
> > > > I didn't like that and preferred majority since (surprise!) I didn't
> > like
> > > > the idea of a veto. I preferred majority approval. [next in thread
> > after
> > > 2]
> > > > Billie said she was neutral about that [second in thread after 2].
> So,
> > I
> > > > set it to majority approval and said anyone can switch it to
> consensus,
> > > > that would be fine [3] (March 4). No one changed it. So, here we are.
> > > >
> > > > The ASF voting guidelines [4] only discuss vetoes in the context of
> > code
> > > > modification. Its section on Procedural Votes is unhelpfully empty.
> > > > However, at the top it says:
> > > >
> > > > Votes on procedural issues follow the common format of majority rule
> > > unless
> > > > otherwise stated. That is, if there are more favourable votes than
> > > > unfavourable ones, the issue is considered to have passed --
> regardless
> > > of
> > > > the number of votes in each category. (If the number of votes seems
> too
> > > > small to be representative of a community consensus, the issue is
> > > typically
> > > > not pursued. However, see the description of lazy consensus for a
> > > modifying
> > > > factor.)
> > > >
> > > >
> > > > When I called this vote, I decided that since the bylaws stated
> > majority
> > > > approval for modifications, the vote should be majority approval.
> There
> > > was
> > > > time for the community to deliberate about it before the vote, so
> > absent
> > > > any concern (that I recall seeing) it was the consistent choice. (In
> > > fact,
> > > > the first vote Mike called on March 10 was also majority approval.)
> > > >
> > > > That is my rationale for majority approval in this vote.
> > > >
> > > > Bill
> > > >
> > > > [1] http://zookeeper.apache.org/bylaws.html
> > > > [2]
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/accumulo-dev/201402.mbox/%3CCAF1jEfDsHU_tG94TNs-=Mss65geDp2yvxEmpGR1KzQ5Gsb-+9A@mail.gmail.com%3E
> > > > [3]
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/accumulo-dev/201403.mbox/%3CCAD-fFU+SX7aE0cMu5AC9xVR0OxwGeMm-V0O0rNpeQCnxuvAr0Q@mail.gmail.com%3E
> > > > [4] http://www.apache.org/foundation/voting.html
> > > >
> > > >
> > > > On Thu, Apr 3, 2014 at 4:03 PM, Christopher <ctubbsii@apache.org>
> > wrote:
> > > >
> > > > > Unfortunately, I think I'm going to have to change my vote to a -1,
> > > > > based on the point that John just brought up.
> > > > >
> > > > > After some thought, I'm not sure it makes sense for people to be
> > bound
> > > > > by operating rules they did not agree to, especially for the
> initial
> > > > > adoption. I think consensus approval makes more sense for modifying
> > > > > the bylaws (and for the initial adoption of those bylaws) than does
> > > > > majority approval.
> > > > >
> > > > > --
> > > > > Christopher L Tubbs II
> > > > > http://gravatar.com/ctubbsii
> > > > >
> > > > >
> > > > > On Thu, Apr 3, 2014 at 3:32 PM, John Vines <vines@apache.org>
> wrote:
> > > > > > I'm also wondering if modifying bylaws, for now and in the
> future,
> > > > should
> > > > > > be consensus approval. Why is that scaled down to Majority?
> > > > > >
> > > > > >
> > > > > > On Thu, Apr 3, 2014 at 3:13 PM, John Vines <jvines@gmail.com>
> > wrote:
> > > > > >
> > > > > >> -1
> > > > > >>
> > > > > >> There is still no clarity on code change actions, which
I think
> > need
> > > > to
> > > > > be
> > > > > >> resolved before it should pass. It seems to be ambiguous,
> > > > intentionally,
> > > > > >> with the intent to revise later. If that's the case, it
should
> > just
> > > be
> > > > > >> removed until a more definitive guideline can be put in
place.
> Or
> > > just
> > > > > >> point at an existing CTR guideline.
> > > > > >>
> > > > > >>
> > > > > >> On Thu, Apr 3, 2014 at 2:18 PM, Bill Havanki <
> > > > bhavanki@clouderagovt.com
> > > > > >wrote:
> > > > > >>
> > > > > >>> Reminder to all: the bylaw vote ends at 10 AM EDT /
7 AM PDT
> > > tomorrow
> > > > > >>> morning. Majority approval is required.
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>> Bill
> > > > > >>>
> > > > > >>>
> > > > > >>> On Thu, Apr 3, 2014 at 2:13 PM, Mike Drob <madrob@cloudera.com
> >
> > > > wrote:
> > > > > >>>
> > > > > >>> > +1
> > > > > >>> >
> > > > > >>> >
> > > > > >>> > On Wed, Apr 2, 2014 at 6:26 AM, Eric Newton <
> > > eric.newton@gmail.com
> > > > >
> > > > > >>> wrote:
> > > > > >>> >
> > > > > >>> > > +1
> > > > > >>> > >
> > > > > >>> > > Thank you all for working through something
that makes me
> > want
> > > to
> > > > > go
> > > > > >>> back
> > > > > >>> > > to reading gigabytes of debug logs.
> > > > > >>> > >
> > > > > >>> > > -Eric
> > > > > >>> > >
> > > > > >>> > >
> > > > > >>> > >
> > > > > >>> > > On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi
<
> > > > billie@apache.org>
> > > > > >>> > wrote:
> > > > > >>> > >
> > > > > >>> > > > Hey everyone!  We only have 3 more days
to vote on
> > Accumulo's
> > > > > bylaws
> > > > > >>> > ...
> > > > > >>> > > >
> > > > > >>> > > >
> > > > > >>> > > > On Fri, Mar 28, 2014 at 6:55 AM, Bill
Havanki <
> > > > > >>> > bhavanki@clouderagovt.com
> > > > > >>> > > > >wrote:
> > > > > >>> > > >
> > > > > >>> > > > > Please vote on the proposed bylaws,
as available at
> > > > > >>> > > > >
> > > > > >>> > > > > *
> > > > > >>> > > > >
> > > > > >>> > > >
> > > > > >>> > >
> > > > > >>> >
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1582476&view=markup
> > > > > >>> > > > > <
> > > > > >>> > > > >
> > > > > >>> > > >
> > > > > >>> > >
> > > > > >>> >
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1582476&view=markup
> > > > > >>> > > > > >*
> > > > > >>> > > > >
> > > > > >>> > > > > A nicer-to-read version is available
at
> > > > > >>> > > > >
> > > > > >>> > > > > http://accumulo.apache.org/bylaws.html
> > > > > >>> > > > >
> > > > > >>> > > > > This vote will be open for 7 days,
until 4 April 2014
> > 14:00
> > > > > UTC.
> > > > > >>> > > > >
> > > > > >>> > > > > Upon successful completion of this
vote, the first line
> > of
> > > > the
> > > > > >>> > document
> > > > > >>> > > > > body
> > > > > >>> > > > > will be replaced with "This is version
1 of the
> bylaws,"
> > > and
> > > > > the
> > > > > >>> > > > statement
> > > > > >>> > > > > defining the document as a draft
will be stricken.
> > > > > Additionally, a
> > > > > >>> > link
> > > > > >>> > > > to
> > > > > >>> > > > > the document will be added to the
navigation menu.
> > > > > >>> > > > >
> > > > > >>> > > > > This vote requires majority approval
to pass: at least
> 3
> > +1
> > > > > votes
> > > > > >>> and
> > > > > >>> > > > more
> > > > > >>> > > > > +1
> > > > > >>> > > > > than -1's.
> > > > > >>> > > > >
> > > > > >>> > > > > [ ] +1 - "I approve of these proposed
bylaws and accept
> > > them
> > > > > for
> > > > > >>> the
> > > > > >>> > > > > Apache Accumulo
> > > > > >>> > > > > project."
> > > > > >>> > > > > [ ] +0 - "I neither approve nor
disapprove of these
> > > proposed
> > > > > >>> bylaws,
> > > > > >>> > > but
> > > > > >>> > > > > accept them for the Apache Accumulo
project."
> > > > > >>> > > > > [ ] -1 - "I do not approve of these
proposed bylaws and
> > do
> > > > not
> > > > > >>> accept
> > > > > >>> > > > them
> > > > > >>> > > > > for
> > > > > >>> > > > > the Apache Accumulo project because..."
> > > > > >>> > > > >
> > > > > >>> > > > > Thank you.
> > > > > >>> > > > >
> > > > > >>> > > > > --
> > > > > >>> > > > > // Bill Havanki
> > > > > >>> > > > > // Solutions Architect, Cloudera
Govt Solutions
> > > > > >>> > > > > // 443.686.9283
> > > > > >>> > > > >
> > > > > >>> > > >
> > > > > >>> > >
> > > > > >>> >
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> // Bill Havanki
> > > > > >>> // Solutions Architect, Cloudera Govt Solutions
> > > > > >>> // 443.686.9283
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Cheers
> > > > > >> ~John
> > > > > >>
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > // Bill Havanki
> > > > // Solutions Architect, Cloudera Govt Solutions
> > > > // 443.686.9283
> > > >
> > >
> >
> >
> >
> > --
> > // Bill Havanki
> > // Solutions Architect, Cloudera Govt Solutions
> > // 443.686.9283
> >
>



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

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