You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Bill Havanki <bh...@clouderagovt.com> on 2014/03/28 14:55:28 UTC
[VOTE] Accumulo Bylaws, vote 2
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
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Christopher <ct...@apache.org>.
+1 for these bylaws (I agree with Billie that fixing the broken link
shouldn't invalidate the vote).
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Mar 28, 2014 at 9:55 AM, Bill Havanki <bh...@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
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by John Vines <vi...@apache.org>.
So every single potential commit needs to pass a 1 day lazy consensus vote
before it can be pushed. This is the issue I have with the current wording.
On Tue, Apr 1, 2014 at 5:15 PM, Bill Havanki <bh...@clouderagovt.com>wrote:
> First, +1 vote
>
> As part of getting us a (literally) passable first set of bylaws as a
> foundation, at one point I "refactored" the commit and review details out
> to an as-yet-to-be-written standard. So, what is in the bylaws should be
> interpreted as permissive.
>
> My interpretations: A "code change" can certainly be a commit - "a change
> made to a codebase of a project". Lazy approval is based on that commit.
> The minimum voting period (here and for release plan) applies to both vote
> phases separately, so *n* days for lazy approval, *n* days for consensus
> if needed. (I imagine lazy approval has some period since getting a veto
> one month later shouldn't be possible, for example; but if that doesn't
> make sense, never mind. :) )
>
> I have all sorts of ideas about the commit and review details, and I bet
> others do too, which is why I like having that split off from getting some
> version 1 bylaws in place. As the policies evolve, we still have the option
> to modify the bylaws as needed.
>
> Bill
>
>
>
>
>
>
> On Tue, Apr 1, 2014 at 4:40 PM, John Vines <vi...@apache.org> wrote:
>
>> The only two places we have a lazy falling back to another type of vote is
>> code change and release plan. For release plan, I interpret the minimum
>> length to apply to either type of vote. However, you're stating that this
>> is not the case for a code change. So there is ambiguity about minimum
>> length applying to lazy approvals that needs to be cleared up here.
>>
>>
>> On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <billie.rinaldi@gmail.com
>> >wrote:
>>
>> > The only time there is more than one type of approval (not vote)
>> required
>> > is when the first one is lazy consensus, which doesn't actually require
>> a
>> > vote. Maybe we just need some elaboration on how to CTR which is
>> > referenced from this doc ("Please refer to the Accumulo commit and
>> review
>> > standard for details")?
>> >
>> >
>> > On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vi...@apache.org> wrote:
>> >
>> >> If that is the case, then I think we should provide distinction about
>> the
>> >> time lengths between the various types of votes, for the cases where
>> there
>> >> are multiple possible votes involved.
>> >>
>> >>
>> >> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <
>> billie.rinaldi@gmail.com>wrote:
>> >>
>> >>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org> wrote:
>> >>>
>> >>>> The way I'm reading actions, all code changes must be presented at
>> least
>> >>>> one day before they can be committed. Is that intended this way?
>> >>>>
>> >>>
>> >>> I wasn't reading it that way. Code change is lazy approval, and "An
>> >>> action with lazy approval is implicitly allowed unless a -1 vote is
>> >>> received." Not requiring a vote supersedes the minimum vote length.
>> In
>> >>> the event of falling back to consensus approval for code change, the
>> >>> minimum vote length is 1 day.
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@gmail.com>.
On Tue, Apr 1, 2014 at 2:26 PM, Mike Drob <ma...@cloudera.com> wrote:
> I do not like this. It sounds like I can veto a release by putting a veto
> on a commit, when we explicitly state that release votes are majority, not
> consensus.
>
I think that's technically true. However, presumably that would get worked
out earlier as part of the release plan and planning.
>
>
> On Tue, Apr 1, 2014 at 2:20 PM, Billie Rinaldi <billie.rinaldi@gmail.com
> >wrote:
>
> > On Tue, Apr 1, 2014 at 2:15 PM, Bill Havanki <bhavanki@clouderagovt.com
> > >wrote:
> >
> > > First, +1 vote
> > >
> > > As part of getting us a (literally) passable first set of bylaws as a
> > > foundation, at one point I "refactored" the commit and review details
> out
> > > to an as-yet-to-be-written standard. So, what is in the bylaws should
> be
> > > interpreted as permissive.
> > >
> > > My interpretations: A "code change" can certainly be a commit - "a
> change
> > > made to a codebase of a project". Lazy approval is based on that
> commit.
> > > The minimum voting period (here and for release plan) applies to both
> > vote
> > > phases separately, so *n* days for lazy approval, *n* days for
> consensus
> > > if needed. (I imagine lazy approval has some period since getting a
> veto
> > > one month later shouldn't be possible, for example; but if that doesn't
> > > make sense, never mind. :) )
> > >
> >
> > A change can be vetoed until the code is released. :)
> >
> >
> > >
> > > I have all sorts of ideas about the commit and review details, and I
> bet
> > > others do too, which is why I like having that split off from getting
> > some
> > > version 1 bylaws in place. As the policies evolve, we still have the
> > option
> > > to modify the bylaws as needed.
> > >
> > > Bill
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Apr 1, 2014 at 4:40 PM, John Vines <vi...@apache.org> wrote:
> > >
> > >> The only two places we have a lazy falling back to another type of
> vote
> > is
> > >> code change and release plan. For release plan, I interpret the
> minimum
> > >> length to apply to either type of vote. However, you're stating that
> > this
> > >> is not the case for a code change. So there is ambiguity about minimum
> > >> length applying to lazy approvals that needs to be cleared up here.
> > >>
> > >>
> > >> On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <
> > billie.rinaldi@gmail.com
> > >> >wrote:
> > >>
> > >> > The only time there is more than one type of approval (not vote)
> > >> required
> > >> > is when the first one is lazy consensus, which doesn't actually
> > require
> > >> a
> > >> > vote. Maybe we just need some elaboration on how to CTR which is
> > >> > referenced from this doc ("Please refer to the Accumulo commit and
> > >> review
> > >> > standard for details")?
> > >> >
> > >> >
> > >> > On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vi...@apache.org>
> wrote:
> > >> >
> > >> >> If that is the case, then I think we should provide distinction
> about
> > >> the
> > >> >> time lengths between the various types of votes, for the cases
> where
> > >> there
> > >> >> are multiple possible votes involved.
> > >> >>
> > >> >>
> > >> >> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <
> > >> billie.rinaldi@gmail.com>wrote:
> > >> >>
> > >> >>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org>
> > wrote:
> > >> >>>
> > >> >>>> The way I'm reading actions, all code changes must be presented
> at
> > >> least
> > >> >>>> one day before they can be committed. Is that intended this way?
> > >> >>>>
> > >> >>>
> > >> >>> I wasn't reading it that way. Code change is lazy approval, and
> "An
> > >> >>> action with lazy approval is implicitly allowed unless a -1 vote
> is
> > >> >>> received." Not requiring a vote supersedes the minimum vote
> length.
> > >> In
> > >> >>> the event of falling back to consensus approval for code change,
> the
> > >> >>> minimum vote length is 1 day.
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>>>
> > >> >>>>
> > >> >>>> 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
> > >
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Mike Drob <ma...@cloudera.com>.
I do not like this. It sounds like I can veto a release by putting a veto
on a commit, when we explicitly state that release votes are majority, not
consensus.
On Tue, Apr 1, 2014 at 2:20 PM, Billie Rinaldi <bi...@gmail.com>wrote:
> On Tue, Apr 1, 2014 at 2:15 PM, Bill Havanki <bhavanki@clouderagovt.com
> >wrote:
>
> > First, +1 vote
> >
> > As part of getting us a (literally) passable first set of bylaws as a
> > foundation, at one point I "refactored" the commit and review details out
> > to an as-yet-to-be-written standard. So, what is in the bylaws should be
> > interpreted as permissive.
> >
> > My interpretations: A "code change" can certainly be a commit - "a change
> > made to a codebase of a project". Lazy approval is based on that commit.
> > The minimum voting period (here and for release plan) applies to both
> vote
> > phases separately, so *n* days for lazy approval, *n* days for consensus
> > if needed. (I imagine lazy approval has some period since getting a veto
> > one month later shouldn't be possible, for example; but if that doesn't
> > make sense, never mind. :) )
> >
>
> A change can be vetoed until the code is released. :)
>
>
> >
> > I have all sorts of ideas about the commit and review details, and I bet
> > others do too, which is why I like having that split off from getting
> some
> > version 1 bylaws in place. As the policies evolve, we still have the
> option
> > to modify the bylaws as needed.
> >
> > Bill
> >
> >
> >
> >
> >
> >
> > On Tue, Apr 1, 2014 at 4:40 PM, John Vines <vi...@apache.org> wrote:
> >
> >> The only two places we have a lazy falling back to another type of vote
> is
> >> code change and release plan. For release plan, I interpret the minimum
> >> length to apply to either type of vote. However, you're stating that
> this
> >> is not the case for a code change. So there is ambiguity about minimum
> >> length applying to lazy approvals that needs to be cleared up here.
> >>
> >>
> >> On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <
> billie.rinaldi@gmail.com
> >> >wrote:
> >>
> >> > The only time there is more than one type of approval (not vote)
> >> required
> >> > is when the first one is lazy consensus, which doesn't actually
> require
> >> a
> >> > vote. Maybe we just need some elaboration on how to CTR which is
> >> > referenced from this doc ("Please refer to the Accumulo commit and
> >> review
> >> > standard for details")?
> >> >
> >> >
> >> > On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vi...@apache.org> wrote:
> >> >
> >> >> If that is the case, then I think we should provide distinction about
> >> the
> >> >> time lengths between the various types of votes, for the cases where
> >> there
> >> >> are multiple possible votes involved.
> >> >>
> >> >>
> >> >> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <
> >> billie.rinaldi@gmail.com>wrote:
> >> >>
> >> >>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org>
> wrote:
> >> >>>
> >> >>>> The way I'm reading actions, all code changes must be presented at
> >> least
> >> >>>> one day before they can be committed. Is that intended this way?
> >> >>>>
> >> >>>
> >> >>> I wasn't reading it that way. Code change is lazy approval, and "An
> >> >>> action with lazy approval is implicitly allowed unless a -1 vote is
> >> >>> received." Not requiring a vote supersedes the minimum vote length.
> >> In
> >> >>> the event of falling back to consensus approval for code change, the
> >> >>> minimum vote length is 1 day.
> >> >>>
> >> >>>
> >> >>>
> >> >>>>
> >> >>>>
> >> >>>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Bill Havanki <bh...@clouderagovt.com>.
Then my interpretation on the voting period doesn't make sense, so never
mind it. Thanks for clarifying!
On Tue, Apr 1, 2014 at 5:20 PM, Billie Rinaldi <bi...@gmail.com>wrote:
> On Tue, Apr 1, 2014 at 2:15 PM, Bill Havanki <bh...@clouderagovt.com>wrote:
>
>> First, +1 vote
>>
>> As part of getting us a (literally) passable first set of bylaws as a
>> foundation, at one point I "refactored" the commit and review details out
>> to an as-yet-to-be-written standard. So, what is in the bylaws should be
>> interpreted as permissive.
>>
>> My interpretations: A "code change" can certainly be a commit - "a change
>> made to a codebase of a project". Lazy approval is based on that commit.
>> The minimum voting period (here and for release plan) applies to both vote
>> phases separately, so *n* days for lazy approval, *n* days for consensus
>> if needed. (I imagine lazy approval has some period since getting a veto
>> one month later shouldn't be possible, for example; but if that doesn't
>> make sense, never mind. :) )
>>
>
> A change can be vetoed until the code is released. :)
>
>
>>
>> I have all sorts of ideas about the commit and review details, and I bet
>> others do too, which is why I like having that split off from getting some
>> version 1 bylaws in place. As the policies evolve, we still have the option
>> to modify the bylaws as needed.
>>
>> Bill
>>
>>
>>
>>
>>
>>
>> On Tue, Apr 1, 2014 at 4:40 PM, John Vines <vi...@apache.org> wrote:
>>
>>> The only two places we have a lazy falling back to another type of vote
>>> is
>>> code change and release plan. For release plan, I interpret the minimum
>>> length to apply to either type of vote. However, you're stating that this
>>> is not the case for a code change. So there is ambiguity about minimum
>>> length applying to lazy approvals that needs to be cleared up here.
>>>
>>>
>>> On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <billie.rinaldi@gmail.com
>>> >wrote:
>>>
>>> > The only time there is more than one type of approval (not vote)
>>> required
>>> > is when the first one is lazy consensus, which doesn't actually
>>> require a
>>> > vote. Maybe we just need some elaboration on how to CTR which is
>>> > referenced from this doc ("Please refer to the Accumulo commit and
>>> review
>>> > standard for details")?
>>> >
>>> >
>>> > On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vi...@apache.org> wrote:
>>> >
>>> >> If that is the case, then I think we should provide distinction about
>>> the
>>> >> time lengths between the various types of votes, for the cases where
>>> there
>>> >> are multiple possible votes involved.
>>> >>
>>> >>
>>> >> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <
>>> billie.rinaldi@gmail.com>wrote:
>>> >>
>>> >>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org>
>>> wrote:
>>> >>>
>>> >>>> The way I'm reading actions, all code changes must be presented at
>>> least
>>> >>>> one day before they can be committed. Is that intended this way?
>>> >>>>
>>> >>>
>>> >>> I wasn't reading it that way. Code change is lazy approval, and "An
>>> >>> action with lazy approval is implicitly allowed unless a -1 vote is
>>> >>> received." Not requiring a vote supersedes the minimum vote length.
>>> In
>>> >>> the event of falling back to consensus approval for code change, the
>>> >>> minimum vote length is 1 day.
>>> >>>
>>> >>>
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
>>
>
>
--
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@gmail.com>.
On Tue, Apr 1, 2014 at 2:15 PM, Bill Havanki <bh...@clouderagovt.com>wrote:
> First, +1 vote
>
> As part of getting us a (literally) passable first set of bylaws as a
> foundation, at one point I "refactored" the commit and review details out
> to an as-yet-to-be-written standard. So, what is in the bylaws should be
> interpreted as permissive.
>
> My interpretations: A "code change" can certainly be a commit - "a change
> made to a codebase of a project". Lazy approval is based on that commit.
> The minimum voting period (here and for release plan) applies to both vote
> phases separately, so *n* days for lazy approval, *n* days for consensus
> if needed. (I imagine lazy approval has some period since getting a veto
> one month later shouldn't be possible, for example; but if that doesn't
> make sense, never mind. :) )
>
A change can be vetoed until the code is released. :)
>
> I have all sorts of ideas about the commit and review details, and I bet
> others do too, which is why I like having that split off from getting some
> version 1 bylaws in place. As the policies evolve, we still have the option
> to modify the bylaws as needed.
>
> Bill
>
>
>
>
>
>
> On Tue, Apr 1, 2014 at 4:40 PM, John Vines <vi...@apache.org> wrote:
>
>> The only two places we have a lazy falling back to another type of vote is
>> code change and release plan. For release plan, I interpret the minimum
>> length to apply to either type of vote. However, you're stating that this
>> is not the case for a code change. So there is ambiguity about minimum
>> length applying to lazy approvals that needs to be cleared up here.
>>
>>
>> On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <billie.rinaldi@gmail.com
>> >wrote:
>>
>> > The only time there is more than one type of approval (not vote)
>> required
>> > is when the first one is lazy consensus, which doesn't actually require
>> a
>> > vote. Maybe we just need some elaboration on how to CTR which is
>> > referenced from this doc ("Please refer to the Accumulo commit and
>> review
>> > standard for details")?
>> >
>> >
>> > On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vi...@apache.org> wrote:
>> >
>> >> If that is the case, then I think we should provide distinction about
>> the
>> >> time lengths between the various types of votes, for the cases where
>> there
>> >> are multiple possible votes involved.
>> >>
>> >>
>> >> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <
>> billie.rinaldi@gmail.com>wrote:
>> >>
>> >>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org> wrote:
>> >>>
>> >>>> The way I'm reading actions, all code changes must be presented at
>> least
>> >>>> one day before they can be committed. Is that intended this way?
>> >>>>
>> >>>
>> >>> I wasn't reading it that way. Code change is lazy approval, and "An
>> >>> action with lazy approval is implicitly allowed unless a -1 vote is
>> >>> received." Not requiring a vote supersedes the minimum vote length.
>> In
>> >>> the event of falling back to consensus approval for code change, the
>> >>> minimum vote length is 1 day.
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Bill Havanki <bh...@clouderagovt.com>.
First, +1 vote
As part of getting us a (literally) passable first set of bylaws as a
foundation, at one point I "refactored" the commit and review details out
to an as-yet-to-be-written standard. So, what is in the bylaws should be
interpreted as permissive.
My interpretations: A "code change" can certainly be a commit - "a change
made to a codebase of a project". Lazy approval is based on that commit.
The minimum voting period (here and for release plan) applies to both vote
phases separately, so *n* days for lazy approval, *n* days for consensus if
needed. (I imagine lazy approval has some period since getting a veto one
month later shouldn't be possible, for example; but if that doesn't make
sense, never mind. :) )
I have all sorts of ideas about the commit and review details, and I bet
others do too, which is why I like having that split off from getting some
version 1 bylaws in place. As the policies evolve, we still have the option
to modify the bylaws as needed.
Bill
On Tue, Apr 1, 2014 at 4:40 PM, John Vines <vi...@apache.org> wrote:
> The only two places we have a lazy falling back to another type of vote is
> code change and release plan. For release plan, I interpret the minimum
> length to apply to either type of vote. However, you're stating that this
> is not the case for a code change. So there is ambiguity about minimum
> length applying to lazy approvals that needs to be cleared up here.
>
>
> On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <billie.rinaldi@gmail.com
> >wrote:
>
> > The only time there is more than one type of approval (not vote) required
> > is when the first one is lazy consensus, which doesn't actually require a
> > vote. Maybe we just need some elaboration on how to CTR which is
> > referenced from this doc ("Please refer to the Accumulo commit and review
> > standard for details")?
> >
> >
> > On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vi...@apache.org> wrote:
> >
> >> If that is the case, then I think we should provide distinction about
> the
> >> time lengths between the various types of votes, for the cases where
> there
> >> are multiple possible votes involved.
> >>
> >>
> >> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <
> billie.rinaldi@gmail.com>wrote:
> >>
> >>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org> wrote:
> >>>
> >>>> The way I'm reading actions, all code changes must be presented at
> least
> >>>> one day before they can be committed. Is that intended this way?
> >>>>
> >>>
> >>> I wasn't reading it that way. Code change is lazy approval, and "An
> >>> action with lazy approval is implicitly allowed unless a -1 vote is
> >>> received." Not requiring a vote supersedes the minimum vote length.
> In
> >>> the event of falling back to consensus approval for code change, the
> >>> minimum vote length is 1 day.
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@gmail.com>.
I think the problem is that we're actually dealing with two flavors of lazy
consensus, one where you explicitly state "if no one disagrees by X then
I'm doing Y," and another where you do Y, and assume it is approved if no
one objects. For the former, you need some kind of minimum length to
announce. But for the latter, which is what happens under CTR, a length
doesn't make sense. ASF documentation is not entirely clear on this
distinction (the examples of lazy consensus are all of the first type, but
it also says that CTR is an application of decision making through lazy
consensus). That's why I think a good description of CTR would resolve the
issue.
On Tue, Apr 1, 2014 at 1:40 PM, John Vines <vi...@apache.org> wrote:
> The only two places we have a lazy falling back to another type of vote is
> code change and release plan. For release plan, I interpret the minimum
> length to apply to either type of vote. However, you're stating that this
> is not the case for a code change. So there is ambiguity about minimum
> length applying to lazy approvals that needs to be cleared up here.
>
>
> On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <bi...@gmail.com>wrote:
>
>> The only time there is more than one type of approval (not vote) required
>> is when the first one is lazy consensus, which doesn't actually require a
>> vote. Maybe we just need some elaboration on how to CTR which is
>> referenced from this doc ("Please refer to the Accumulo commit and review
>> standard for details")?
>>
>>
>> On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vi...@apache.org> wrote:
>>
>>> If that is the case, then I think we should provide distinction about
>>> the time lengths between the various types of votes, for the cases where
>>> there are multiple possible votes involved.
>>>
>>>
>>> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <billie.rinaldi@gmail.com
>>> > wrote:
>>>
>>>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org> wrote:
>>>>
>>>>> The way I'm reading actions, all code changes must be presented at
>>>>> least
>>>>> one day before they can be committed. Is that intended this way?
>>>>>
>>>>
>>>> I wasn't reading it that way. Code change is lazy approval, and "An
>>>> action with lazy approval is implicitly allowed unless a -1 vote is
>>>> received." Not requiring a vote supersedes the minimum vote length. In
>>>> the event of falling back to consensus approval for code change, the
>>>> minimum vote length is 1 day.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by John Vines <vi...@apache.org>.
The only two places we have a lazy falling back to another type of vote is
code change and release plan. For release plan, I interpret the minimum
length to apply to either type of vote. However, you're stating that this
is not the case for a code change. So there is ambiguity about minimum
length applying to lazy approvals that needs to be cleared up here.
On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <bi...@gmail.com>wrote:
> The only time there is more than one type of approval (not vote) required
> is when the first one is lazy consensus, which doesn't actually require a
> vote. Maybe we just need some elaboration on how to CTR which is
> referenced from this doc ("Please refer to the Accumulo commit and review
> standard for details")?
>
>
> On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vi...@apache.org> wrote:
>
>> If that is the case, then I think we should provide distinction about the
>> time lengths between the various types of votes, for the cases where there
>> are multiple possible votes involved.
>>
>>
>> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <bi...@gmail.com>wrote:
>>
>>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org> wrote:
>>>
>>>> The way I'm reading actions, all code changes must be presented at least
>>>> one day before they can be committed. Is that intended this way?
>>>>
>>>
>>> I wasn't reading it that way. Code change is lazy approval, and "An
>>> action with lazy approval is implicitly allowed unless a -1 vote is
>>> received." Not requiring a vote supersedes the minimum vote length. In
>>> the event of falling back to consensus approval for code change, the
>>> minimum vote length is 1 day.
>>>
>>>
>>>
>>>>
>>>>
>>>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
>>>> > >
>>>> >
>>>>
>>>
>>>
>>
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@gmail.com>.
The only time there is more than one type of approval (not vote) required
is when the first one is lazy consensus, which doesn't actually require a
vote. Maybe we just need some elaboration on how to CTR which is
referenced from this doc ("Please refer to the Accumulo commit and review
standard for details")?
On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vi...@apache.org> wrote:
> If that is the case, then I think we should provide distinction about the
> time lengths between the various types of votes, for the cases where there
> are multiple possible votes involved.
>
>
> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <bi...@gmail.com>wrote:
>
>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org> wrote:
>>
>>> The way I'm reading actions, all code changes must be presented at least
>>> one day before they can be committed. Is that intended this way?
>>>
>>
>> I wasn't reading it that way. Code change is lazy approval, and "An
>> action with lazy approval is implicitly allowed unless a -1 vote is
>> received." Not requiring a vote supersedes the minimum vote length. In
>> the event of falling back to consensus approval for code change, the
>> minimum vote length is 1 day.
>>
>>
>>
>>>
>>>
>>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
>>> > >
>>> >
>>>
>>
>>
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by John Vines <vi...@apache.org>.
If that is the case, then I think we should provide distinction about the
time lengths between the various types of votes, for the cases where there
are multiple possible votes involved.
On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <bi...@gmail.com>wrote:
> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org> wrote:
>
>> The way I'm reading actions, all code changes must be presented at least
>> one day before they can be committed. Is that intended this way?
>>
>
> I wasn't reading it that way. Code change is lazy approval, and "An
> action with lazy approval is implicitly allowed unless a -1 vote is
> received." Not requiring a vote supersedes the minimum vote length. In
> the event of falling back to consensus approval for code change, the
> minimum vote length is 1 day.
>
>
>
>>
>>
>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
>> > >
>> >
>>
>
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@gmail.com>.
On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vi...@apache.org> wrote:
> The way I'm reading actions, all code changes must be presented at least
> one day before they can be committed. Is that intended this way?
>
I wasn't reading it that way. Code change is lazy approval, and "An action
with lazy approval is implicitly allowed unless a -1 vote is received."
Not requiring a vote supersedes the minimum vote length. In the event of
falling back to consensus approval for code change, the minimum vote length
is 1 day.
>
>
> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
> > >
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by John Vines <vi...@apache.org>.
The way I'm reading actions, all code changes must be presented at least
one day before they can be committed. Is that intended this way?
On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <bi...@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
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Josh Elser <jo...@gmail.com>.
Re-reading this section of the proposed guidelines does give me pause as
it's not straightforward and can appear counter to what our "commit
guidelines" (ctr presently) are.
Changing my vote to +0 for now. I'd like to see some plan that at least
addresses it before moving forward. Seems silly to release a first round
of bylaws that we aren't all in agreement about, but, at the same time,
I can appreciate the pain getting a 7-day vote passed brings...
On 4/3/14, 3:13 PM, John Vines 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 <bh...@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 <ma...@cloudera.com> wrote:
>>
>>> +1
>>>
>>>
>>> On Wed, Apr 2, 2014 at 6:26 AM, Eric Newton <er...@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 <bi...@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
>>
>
>
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Brian Loss <bf...@praxiseng.com>.
-0
I don’t see the need to push something through that it sounds like we know we’re going to change immediately, especially given that there is opposition to the proposed bylaws. What’s the down side of waiting to get it right now?
I do second Josh’s comments. Thanks Bill and everyone else for the hard work on this!
On Apr 4, 2014, at 12:03 AM, Josh Elser <jo...@gmail.com> wrote:
> Personally, while not voting -1, I still don't quite agree that pushing the first draft of a document to a successful vote that has dissent from more than one PMC member.
>
> To my knowledge, there is no rush to release such a document, so it doesn't make sense to me to release such a document to just turn around and make an amendment to it. Let's get it right the first time and not set a precedent for ignoring the concerns. Community comes first.
>
> Presently, my biggest concern is that there is still some ambiguity about the lazy approval of code changes that John initial brought up. I haven't thought enough about the majority versus consensus rules, but my first impression is, that with good faith, this isn't a big concern that needs to be hashed up front.
>
> Lastly, I want to applaud Bill for stepping up to spearhead this. The frustration with this process, akin to that which we face for every release, is unavoidable. No, the community as a whole does not always (ever?) read everything up front, and that is the difficulty in working as a group. However, I do not feel like just because someone missed the "preferred" time window to voice a concern means that those concerns are no longer valid at the given moment. Just as we wouldn't treat an issue found in an RC during the last hour of the vote differently than an issue found before the RC was made (everyone would much rather the latter always be the case), discussion that was raised late in the game is just as important as discussion raised before the approval vote.
>
> On 4/3/14, 8:14 PM, Sean Busbey 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 <ma...@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.
>>>>>
>>>>
>>>
>>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Josh Elser <jo...@gmail.com>.
Personally, while not voting -1, I still don't quite agree that pushing
the first draft of a document to a successful vote that has dissent from
more than one PMC member.
To my knowledge, there is no rush to release such a document, so it
doesn't make sense to me to release such a document to just turn around
and make an amendment to it. Let's get it right the first time and not
set a precedent for ignoring the concerns. Community comes first.
Presently, my biggest concern is that there is still some ambiguity
about the lazy approval of code changes that John initial brought up. I
haven't thought enough about the majority versus consensus rules, but my
first impression is, that with good faith, this isn't a big concern that
needs to be hashed up front.
Lastly, I want to applaud Bill for stepping up to spearhead this. The
frustration with this process, akin to that which we face for every
release, is unavoidable. No, the community as a whole does not always
(ever?) read everything up front, and that is the difficulty in working
as a group. However, I do not feel like just because someone missed the
"preferred" time window to voice a concern means that those concerns are
no longer valid at the given moment. Just as we wouldn't treat an issue
found in an RC during the last hour of the vote differently than an
issue found before the RC was made (everyone would much rather the
latter always be the case), discussion that was raised late in the game
is just as important as discussion raised before the approval vote.
On 4/3/14, 8:14 PM, Sean Busbey 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 <ma...@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.
>>>>
>>>
>>
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Bill Havanki <bh...@clouderagovt.com>.
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 <bi...@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 <ct...@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 <bu...@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 <ma...@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
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@gmail.com>.
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 <ct...@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 <bu...@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 <ma...@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.
> >> > >
> >> >
> >>
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Christopher <ct...@apache.org>.
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 <bu...@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 <ma...@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.
>> > >
>> >
>>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Sean Busbey <bu...@cloudera.com>.
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 <ma...@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.
> > >
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Mike Drob <ma...@cloudera.com>.
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 <bi...@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.
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@gmail.com>.
On Thu, Apr 3, 2014 at 3:37 PM, Sean Busbey <bu...@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.
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Apr 3, 2014 at 5:14 PM, Billie Rinaldi <bi...@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.
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.
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Bill Havanki <bh...@clouderagovt.com>.
<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 <bi...@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 <ma...@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 <ct...@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 <vi...@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 <jv...@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
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@gmail.com>.
On Thu, Apr 3, 2014 at 1:57 PM, Bill Havanki <bh...@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 <ma...@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 <ct...@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 <vi...@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 <jv...@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 <ma...@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
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Corey Nolet <cj...@gmail.com>.
I finally got a chance to fully read through the bylaws and this email
thread.
+1 to approval for the bylaws. Thanks for writing these up!
On Thu, Apr 3, 2014 at 9:59 PM, Sean Busbey <bu...@cloudera.com>wrote:
> Corey,
>
> Just for clarity, is your +1 to Benson's sentiment or to the Bylaws Vote
> for this thread?
>
> -Sean
>
>
> On Thu, Apr 3, 2014 at 8:58 PM, Corey Nolet <cj...@gmail.com> wrote:
>
> > +1
> >
> >
> >
> >
> > On Thu, Apr 3, 2014 at 8:45 PM, Benson Margulies <bimargulies@gmail.com
> > >wrote:
> >
> > > If you're all going to go spelunking in the Apache policy docs,
> > > perhaps I can help a bit with context.
> > >
> > > The original HTTPD project developed a very specific set of policies
> > > for controlling _commits to the code base_. The ballet of
> > > -1/veto/justification comes out of there. The overall foundation
> > > policy is an expectation that all projects will apply that same
> > > approach to commits unless they can state a very good reason to do
> > > something else.
> > >
> > > Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto.
> > > Justification is polite, but not required. Proceeding in the face of a
> > > -1 is not always a good idea, but the policy envisions it; it
> > > envisions that someone might vote -1 because they _might prefer_ to
> > > wait for some other change. But they can just be outvoted.
> > >
> > > Once you get past commits to the codebase and releases, you're more on
> > > your own in deciding how to decide. The particular case at hand, these
> > > bylaws, is an interesting one.
> > >
> > > People should be really clear about what they mean when they propose
> > > consensus as a process. Yes, a consensus process is a process in which
> > > every member of the community has a veto. However, it is also a
> > > process in which every member of the community feels a grave weight of
> > > responsibility in using that veto. Focussing on the veto in a
> > > consensus process is not a good sign.
> > >
> > > Consensus is a slow, deliberative, process, chosen by communities
> > > which value group cohesion over most everything else. It is also a
> > > process that presumes that there is a _status quo_ which is always
> > > acceptable. The community sticks to the status quo until everyone
> > > involved is ready to accept some change. This approach to
> > > decision-making is pretty hard to apply to a new group trying to chart
> > > a new course.
> > >
> > > It is _not_ foundation policy to expect communities to choose
> > > full-blown consensus as the predominant process. Typically, in my
> > > experience, Apache projects do not do full consensus process. Instead,
> > > they strive to give everyone a voice and seek consensus, but
> > > eventually decide via a majority of some kind. Most of the time, the
> > > first part of that (open discussion) achieves a consensus, so that the
> > > second part of that becomes a formality. However, from time to time,
> > > the community chooses to decide by majority in order to decide. The
> > > touchstone of a healthy community is that the minority feel heard and
> > > not steamrolled.
> > >
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Sean Busbey <bu...@cloudera.com>.
Corey,
Just for clarity, is your +1 to Benson's sentiment or to the Bylaws Vote
for this thread?
-Sean
On Thu, Apr 3, 2014 at 8:58 PM, Corey Nolet <cj...@gmail.com> wrote:
> +1
>
>
>
>
> On Thu, Apr 3, 2014 at 8:45 PM, Benson Margulies <bimargulies@gmail.com
> >wrote:
>
> > If you're all going to go spelunking in the Apache policy docs,
> > perhaps I can help a bit with context.
> >
> > The original HTTPD project developed a very specific set of policies
> > for controlling _commits to the code base_. The ballet of
> > -1/veto/justification comes out of there. The overall foundation
> > policy is an expectation that all projects will apply that same
> > approach to commits unless they can state a very good reason to do
> > something else.
> >
> > Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto.
> > Justification is polite, but not required. Proceeding in the face of a
> > -1 is not always a good idea, but the policy envisions it; it
> > envisions that someone might vote -1 because they _might prefer_ to
> > wait for some other change. But they can just be outvoted.
> >
> > Once you get past commits to the codebase and releases, you're more on
> > your own in deciding how to decide. The particular case at hand, these
> > bylaws, is an interesting one.
> >
> > People should be really clear about what they mean when they propose
> > consensus as a process. Yes, a consensus process is a process in which
> > every member of the community has a veto. However, it is also a
> > process in which every member of the community feels a grave weight of
> > responsibility in using that veto. Focussing on the veto in a
> > consensus process is not a good sign.
> >
> > Consensus is a slow, deliberative, process, chosen by communities
> > which value group cohesion over most everything else. It is also a
> > process that presumes that there is a _status quo_ which is always
> > acceptable. The community sticks to the status quo until everyone
> > involved is ready to accept some change. This approach to
> > decision-making is pretty hard to apply to a new group trying to chart
> > a new course.
> >
> > It is _not_ foundation policy to expect communities to choose
> > full-blown consensus as the predominant process. Typically, in my
> > experience, Apache projects do not do full consensus process. Instead,
> > they strive to give everyone a voice and seek consensus, but
> > eventually decide via a majority of some kind. Most of the time, the
> > first part of that (open discussion) achieves a consensus, so that the
> > second part of that becomes a formality. However, from time to time,
> > the community chooses to decide by majority in order to decide. The
> > touchstone of a healthy community is that the minority feel heard and
> > not steamrolled.
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Corey Nolet <cj...@gmail.com>.
+1
On Thu, Apr 3, 2014 at 8:45 PM, Benson Margulies <bi...@gmail.com>wrote:
> If you're all going to go spelunking in the Apache policy docs,
> perhaps I can help a bit with context.
>
> The original HTTPD project developed a very specific set of policies
> for controlling _commits to the code base_. The ballet of
> -1/veto/justification comes out of there. The overall foundation
> policy is an expectation that all projects will apply that same
> approach to commits unless they can state a very good reason to do
> something else.
>
> Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto.
> Justification is polite, but not required. Proceeding in the face of a
> -1 is not always a good idea, but the policy envisions it; it
> envisions that someone might vote -1 because they _might prefer_ to
> wait for some other change. But they can just be outvoted.
>
> Once you get past commits to the codebase and releases, you're more on
> your own in deciding how to decide. The particular case at hand, these
> bylaws, is an interesting one.
>
> People should be really clear about what they mean when they propose
> consensus as a process. Yes, a consensus process is a process in which
> every member of the community has a veto. However, it is also a
> process in which every member of the community feels a grave weight of
> responsibility in using that veto. Focussing on the veto in a
> consensus process is not a good sign.
>
> Consensus is a slow, deliberative, process, chosen by communities
> which value group cohesion over most everything else. It is also a
> process that presumes that there is a _status quo_ which is always
> acceptable. The community sticks to the status quo until everyone
> involved is ready to accept some change. This approach to
> decision-making is pretty hard to apply to a new group trying to chart
> a new course.
>
> It is _not_ foundation policy to expect communities to choose
> full-blown consensus as the predominant process. Typically, in my
> experience, Apache projects do not do full consensus process. Instead,
> they strive to give everyone a voice and seek consensus, but
> eventually decide via a majority of some kind. Most of the time, the
> first part of that (open discussion) achieves a consensus, so that the
> second part of that becomes a formality. However, from time to time,
> the community chooses to decide by majority in order to decide. The
> touchstone of a healthy community is that the minority feel heard and
> not steamrolled.
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by John Vines <vi...@apache.org>.
By those glossary definitions, we're misusing veto throughout the majority
of our bylaws, so we need to rewrite them to clarify the terminology,
either by rewording it to not use veto or to redefine veto for our project.
On Thu, Apr 3, 2014 at 5:28 PM, Mike Drob <ma...@cloudera.com> wrote:
> Some ASF definitions:
>
> From the ASF Voting Process page[1]
>
> To prevent vetos from being used capriciously, they must be accompanied by
> a technical justification showing why the change is bad (opens a security
> exposure, negatively affects performance, *etc.* ). A veto without a
> justification is invalid and has no weight.
>
> So an individual already cannot veto "just because" and must provide a
> reason. From our bylaws:
>
> A valid, binding veto cannot be overruled. If a veto is cast, it must be
> accompanied by a valid reason explaining the veto. The validity of a veto,
> if challenged, can be confirmed by anyone who has a binding vote. This does
> not necessarily signify agreement with the veto, but merely that the veto
> is valid.
>
> If you disagree with a valid veto, you must lobby the person casting the
> veto to withdraw their veto. If a veto is not withdrawn, the action that
> has been vetoed must be reversed in a timely manner.
>
> So it looks like we've got that part covered. Further, from the ASF
> glossary on veto[2]
> According to the Apache methodology, a change which has been made or
> proposed may be made moot through the exercise of a veto by a committer to
> the codebase <http://www.apache.org/foundation/glossary.html#Codebase> in
> question. If the
> R-T-C<http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> >commit
> policy is in effect, a veto prevents the change from being made. In
> either the R-T-C or
> C-T-R<http://www.apache.org/foundation/glossary.html#CommitThenReview
> >environments,
> a veto applied to a change that has already been made forces
> it to be reverted. Vetos may not be overridden nor voted down, and only
> cease to apply when the committer who issued the veto withdraws it. All
> vetos *must* be accompanied by a valid technical justification; a veto
> without such a justification is invalid; in case of doubt, deciding whether
> a technical justification is valid is up to the PMC. Vetos force discussion
> and, if supported, version control rollback or appropriate code changes.
> Vetoed code commits are best reverted by the original committer, unless an
> urgent solution is needed (e.g., build breakers). Vetos only apply to code
> changes; they do not apply to procedural issues such as software releases.
>
> Based on this, a veto can only be applied to code, not to process. Changing
> the bylaws is a matter of process, not code, and I feel that it should be
> majority for consistency with the rest of the ASF.
>
>
> [1] https://www.apache.org/foundation/voting.html#Veto
>
> [2] http://www.apache.org/foundation/glossary.html#Veto
>
>
> On Thu, Apr 3, 2014 at 2:04 PM, Keith Turner <ke...@deenlo.com> wrote:
>
> > On Thu, Apr 3, 2014 at 4: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
> > >
> >
> > No one should be able to veto "just because". A veto should have a
> > defensible reason. Also if someone is not willing to defend their veto,
> is
> > it valid? If someone votes -1 and never answers questions about their
> > position, can that vote be ignored?
> >
> >
> > > 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.
> > >
> > > 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 <ma...@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 <ct...@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 <vi...@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 <jv...@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
> > >
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Benson Margulies <bi...@gmail.com>.
If you're all going to go spelunking in the Apache policy docs,
perhaps I can help a bit with context.
The original HTTPD project developed a very specific set of policies
for controlling _commits to the code base_. The ballet of
-1/veto/justification comes out of there. The overall foundation
policy is an expectation that all projects will apply that same
approach to commits unless they can state a very good reason to do
something else.
Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto.
Justification is polite, but not required. Proceeding in the face of a
-1 is not always a good idea, but the policy envisions it; it
envisions that someone might vote -1 because they _might prefer_ to
wait for some other change. But they can just be outvoted.
Once you get past commits to the codebase and releases, you're more on
your own in deciding how to decide. The particular case at hand, these
bylaws, is an interesting one.
People should be really clear about what they mean when they propose
consensus as a process. Yes, a consensus process is a process in which
every member of the community has a veto. However, it is also a
process in which every member of the community feels a grave weight of
responsibility in using that veto. Focussing on the veto in a
consensus process is not a good sign.
Consensus is a slow, deliberative, process, chosen by communities
which value group cohesion over most everything else. It is also a
process that presumes that there is a _status quo_ which is always
acceptable. The community sticks to the status quo until everyone
involved is ready to accept some change. This approach to
decision-making is pretty hard to apply to a new group trying to chart
a new course.
It is _not_ foundation policy to expect communities to choose
full-blown consensus as the predominant process. Typically, in my
experience, Apache projects do not do full consensus process. Instead,
they strive to give everyone a voice and seek consensus, but
eventually decide via a majority of some kind. Most of the time, the
first part of that (open discussion) achieves a consensus, so that the
second part of that becomes a formality. However, from time to time,
the community chooses to decide by majority in order to decide. The
touchstone of a healthy community is that the minority feel heard and
not steamrolled.
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Mike Drob <ma...@cloudera.com>.
Some ASF definitions:
>From the ASF Voting Process page[1]
To prevent vetos from being used capriciously, they must be accompanied by
a technical justification showing why the change is bad (opens a security
exposure, negatively affects performance, *etc.* ). A veto without a
justification is invalid and has no weight.
So an individual already cannot veto "just because" and must provide a
reason. From our bylaws:
A valid, binding veto cannot be overruled. If a veto is cast, it must be
accompanied by a valid reason explaining the veto. The validity of a veto,
if challenged, can be confirmed by anyone who has a binding vote. This does
not necessarily signify agreement with the veto, but merely that the veto
is valid.
If you disagree with a valid veto, you must lobby the person casting the
veto to withdraw their veto. If a veto is not withdrawn, the action that
has been vetoed must be reversed in a timely manner.
So it looks like we've got that part covered. Further, from the ASF
glossary on veto[2]
According to the Apache methodology, a change which has been made or
proposed may be made moot through the exercise of a veto by a committer to
the codebase <http://www.apache.org/foundation/glossary.html#Codebase> in
question. If the
R-T-C<http://www.apache.org/foundation/glossary.html#ReviewThenCommit>commit
policy is in effect, a veto prevents the change from being made. In
either the R-T-C or
C-T-R<http://www.apache.org/foundation/glossary.html#CommitThenReview>environments,
a veto applied to a change that has already been made forces
it to be reverted. Vetos may not be overridden nor voted down, and only
cease to apply when the committer who issued the veto withdraws it. All
vetos *must* be accompanied by a valid technical justification; a veto
without such a justification is invalid; in case of doubt, deciding whether
a technical justification is valid is up to the PMC. Vetos force discussion
and, if supported, version control rollback or appropriate code changes.
Vetoed code commits are best reverted by the original committer, unless an
urgent solution is needed (e.g., build breakers). Vetos only apply to code
changes; they do not apply to procedural issues such as software releases.
Based on this, a veto can only be applied to code, not to process. Changing
the bylaws is a matter of process, not code, and I feel that it should be
majority for consistency with the rest of the ASF.
[1] https://www.apache.org/foundation/voting.html#Veto
[2] http://www.apache.org/foundation/glossary.html#Veto
On Thu, Apr 3, 2014 at 2:04 PM, Keith Turner <ke...@deenlo.com> wrote:
> On Thu, Apr 3, 2014 at 4: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
> >
>
> No one should be able to veto "just because". A veto should have a
> defensible reason. Also if someone is not willing to defend their veto, is
> it valid? If someone votes -1 and never answers questions about their
> position, can that vote be ignored?
>
>
> > 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.
> >
> > 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 <ma...@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 <ct...@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 <vi...@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 <jv...@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
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Keith Turner <ke...@deenlo.com>.
On Thu, Apr 3, 2014 at 4:57 PM, Bill Havanki <bh...@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
>
No one should be able to veto "just because". A veto should have a
defensible reason. Also if someone is not willing to defend their veto, is
it valid? If someone votes -1 and never answers questions about their
position, can that vote be ignored?
> 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.
>
> 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 <ma...@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 <ct...@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 <vi...@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 <jv...@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 <ma...@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
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Bill Havanki <bh...@clouderagovt.com>.
<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.
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 <ma...@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 <ct...@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 <vi...@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 <jv...@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 <ma...@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
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Mike Drob <ma...@cloudera.com>.
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 <bh...@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 <ct...@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 <vi...@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 <jv...@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 <ma...@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
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Bill Havanki <bh...@clouderagovt.com>.
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 <ct...@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 <vi...@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 <jv...@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 <ma...@cloudera.com> wrote:
> >>>
> >>> > +1
> >>> >
> >>> >
> >>> > On Wed, Apr 2, 2014 at 6:26 AM, Eric Newton <er...@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 <bi...@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
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Christopher <ct...@apache.org>.
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 <vi...@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 <jv...@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 <bh...@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 <ma...@cloudera.com> wrote:
>>>
>>> > +1
>>> >
>>> >
>>> > On Wed, Apr 2, 2014 at 6:26 AM, Eric Newton <er...@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 <bi...@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
>>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by John Vines <vi...@apache.org>.
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 <jv...@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 <bh...@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 <ma...@cloudera.com> wrote:
>>
>> > +1
>> >
>> >
>> > On Wed, Apr 2, 2014 at 6:26 AM, Eric Newton <er...@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 <bi...@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
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by John Vines <jv...@gmail.com>.
-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 <bh...@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 <ma...@cloudera.com> wrote:
>
> > +1
> >
> >
> > On Wed, Apr 2, 2014 at 6:26 AM, Eric Newton <er...@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 <bi...@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
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Bill Havanki <bh...@clouderagovt.com>.
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 <ma...@cloudera.com> wrote:
> +1
>
>
> On Wed, Apr 2, 2014 at 6:26 AM, Eric Newton <er...@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 <bi...@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
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Mike Drob <ma...@cloudera.com>.
+1
On Wed, Apr 2, 2014 at 6:26 AM, Eric Newton <er...@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 <bi...@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
> > >
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Eric Newton <er...@gmail.com>.
+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 <bi...@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
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@apache.org>.
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 <bh...@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
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Sean Busbey <bu...@cloudera.com>.
In that case, +1
On Fri, Mar 28, 2014 at 11:43 AM, Billie Rinaldi
<bi...@gmail.com>wrote:
> I don't think fixing broken links invalidates this vote. Just fix them and
> let's keep it going.
>
>
> On Fri, Mar 28, 2014 at 9:33 AM, Sean Busbey <busbey+lists@cloudera.com
> >wrote:
>
> > Line 103 incorrectly links to the release mechanism page[1] both when it
> > should and when it should link to the release governance page[2].
> >
> > Sorry I hadn't noticed it pre-vote. Keep it in a follow on? Or start
> Vote 3
> > while Vote 2 is still in progress?
> >
> > [1]: http://accumulo.apache.org/releasing.html
> > [2]: http://accumulo.apache.org/governance/releasing.html
> >
> >
> > On Fri, Mar 28, 2014 at 8: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
> > >
> >
>
--
Sean Busbey
Software Engineer
Cloudera, Inc.
Phone: MAN-VS-BEARD
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@gmail.com>.
I don't think fixing broken links invalidates this vote. Just fix them and
let's keep it going.
On Fri, Mar 28, 2014 at 9:33 AM, Sean Busbey <bu...@cloudera.com>wrote:
> Line 103 incorrectly links to the release mechanism page[1] both when it
> should and when it should link to the release governance page[2].
>
> Sorry I hadn't noticed it pre-vote. Keep it in a follow on? Or start Vote 3
> while Vote 2 is still in progress?
>
> [1]: http://accumulo.apache.org/releasing.html
> [2]: http://accumulo.apache.org/governance/releasing.html
>
>
> On Fri, Mar 28, 2014 at 8: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
> >
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Sean Busbey <bu...@cloudera.com>.
Line 103 incorrectly links to the release mechanism page[1] both when it
should and when it should link to the release governance page[2].
Sorry I hadn't noticed it pre-vote. Keep it in a follow on? Or start Vote 3
while Vote 2 is still in progress?
[1]: http://accumulo.apache.org/releasing.html
[2]: http://accumulo.apache.org/governance/releasing.html
On Fri, Mar 28, 2014 at 8:55 AM, Bill Havanki <bh...@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
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Billie Rinaldi <bi...@apache.org>.
+1
On Fri, Mar 28, 2014 at 6:55 AM, Bill Havanki <bh...@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
>
Re: [VOTE] Accumulo Bylaws, vote 2
Posted by Josh Elser <jo...@gmail.com>.
+1 LGTM
On 3/28/14, 6:55 AM, Bill Havanki 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.
>