Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of billie.rinaldi@gmail.com
 designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAD-fFUL+GvUQ0U+qwre0aiNNYKAeRHTAUGcRovjjLNYD+7hV+A@mail.gmail.com>
References: 
 <CAF1jEfCEUntFXbtn3whuaehfM+4CQ7sTZr2C+ru559iK5Y8eLA@mail.gmail.com>
	<CAF1jEfAB2he3i+1VCq1U9tgoqtxSZJZT4OMRgzOhzo2q3eMLYQ@mail.gmail.com>
	<CAF1jEfA0C_gw2nX7VaAi5N=1gGsNKSo0mNx3QYzi3NUg8oJLRQ@mail.gmail.com>
	<CAD-fFUL+GvUQ0U+qwre0aiNNYKAeRHTAUGcRovjjLNYD+7hV+A@mail.gmail.com>
Date: Mon, 14 Apr 2014 10:13:18 -0700
Message-ID: 
 <CAF1jEfCCPoY+0UUuyCdf8hr+NVcnDWtYwdO_yZwaYxTxLQGGiw@mail.gmail.com>
Subject: Re: [VOTE] Define CTR in Bylaws
From: Billie Rinaldi <billie.rinaldi@gmail.com>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2f0acb6bd3b04f703cc22

--001a11c2f0acb6bd3b04f703cc22
Content-Type: text/plain; charset=UTF-8

Good point.  I've fixed it.


On Mon, Apr 14, 2014 at 10:10 AM, Bill Havanki <bhavanki@clouderagovt.com>wrote:

> Should the bylaws now be "version 2"?
>
>
> On Mon, Apr 14, 2014 at 12:21 PM, Billie Rinaldi
> <billie.rinaldi@gmail.com>wrote:
>
> > I committed the change to the bylaws.  Note that I also had to convert
> the
> > lazy consensus link to standard html instead of markdown since it was in
> a
> > table.
> >
> > On Mon, Apr 14, 2014 at 8:04 AM, Billie Rinaldi <
> billie.rinaldi@gmail.com
> > >wrote:
> >
> > > This vote passes with 6 +1 votes from PMC members and no other votes.
> > >
> > >
> > > On Mon, Apr 7, 2014 at 7:11 AM, Billie Rinaldi <billie@apache.org>
> > wrote:
> > >
> > >> Please vote on applying the following changes to the Accumulo bylaws (
> > >> http://accumulo.apache.org/bylaws.html).  If the "Code Change" action
> > >> has been removed, it will be reintroduced along with these changes.
> > >>
> > >> This vote will remain open for 7 days and requires majority approval
> to
> > >> pass.
> > >>
> > >> [ ] +1 - "I approve of these proposed bylaw changes and accept them
> > >> for the Apache
> > >> Accumulo project."
> > >> [ ] +0 - "I neither approve nor disapprove of these proposed bylaw
> > >> changes,
> > >> but accept them for the Apache Accumulo project."
> > >> [ ] -1 - "I do not approve of these proposed bylaw changes and do not
> > >> accept them for the Apache Accumulo project because..."
> > >>
> > >>
> > >> Index: bylaws.mdtext
> > >> ==============================
> > >> =====================================
> > >> --- bylaws.mdtext    (revision 1584734)
> > >> +++ bylaws.mdtext    (working copy)
> > >> @@ -125,8 +125,15 @@
> > >>
> > >>  All participants in the Accumulo project are encouraged to vote. For
> > >> technical decisions, only the votes of active committers are binding.
> > >> Non-binding votes are still useful for those with binding votes to
> > >> understand the perception of an action across the wider Accumulo
> > community.
> > >> For PMC decisions, only the votes of active PMC members are binding.
> > >>
> > >> -Voting can also be applied to changes to the Accumulo codebase.
> Please
> > >> refer to the Accumulo commit and review standard for details.
> > >> +See the [voting page](
> > http://accumulo.apache.org/governance/voting.html)
> > >> for more details on the mechanics of voting.
> > >>
> > >> +<a name="CTR"></a>
> > >> +## Commit Then Review (CTR)
> > >> +
> > >> +Voting can also be applied to changes to the Accumulo codebase. Under
> > >> the Commit Then Review policy, committers can make changes to the
> > codebase
> > >> without seeking approval beforehand, and the changes are assumed to be
> > >> approved unless an objection is raised. Only if an objection is raised
> > must
> > >> a vote take place on the code change.
> > >> +
> > >> +For some code changes, committers may wish to get feedback from the
> > >> community before making the change. It is acceptable for a committer
> to
> > >> seek approval before making a change if they so desire.
> > >> +
> > >>  ## Approvals
> > >>
> > >>  These are the types of approvals that can be sought. Different
> actions
> > >> require different types of approvals.
> > >> @@ -139,7 +146,7 @@
> > >>  <tr><td>Majority Approval</td>
> > >>      <td>A majority approval vote passes with 3 binding +1 votes and
> > more
> > >> binding +1 votes than -1 votes.</td>
> > >>  <tr><td>Lazy Approval (or Lazy Consensus)</td>
> > >> -    <td>An action with lazy approval is implicitly allowed unless a
> -1
> > >> vote is received, at which time, depending on the type of action,
> either
> > >> majority approval or consensus approval must be obtained.</td>
> > >> +    <td>An action with lazy approval is implicitly allowed unless a
> -1
> > >> vote is received, at which time, depending on the type of action,
> either
> > >> majority approval or consensus approval must be obtained.  Lazy
> Approval
> > >> can be either <em>stated</em> or <em>assumed</em>, as detailed on the
> > [lazy
> > >> consensus page](
> > http://accumulo.apache.org/governance/lazyConsensus.html)
> > >> .</td>
> > >>  </table>
> > >>
> > >>  ## Vetoes
> > >> @@ -152,6 +159,8 @@
> > >>
> > >>  This section describes the various actions which are undertaken
> within
> > >> the project, the corresponding approval required for that action and
> > those
> > >> who have binding votes over the action. It also specifies the minimum
> > >> length of time that a vote must remain open, measured in days. In
> > general,
> > >> votes should not be called at times when it is known that interested
> > >> members of the project will be unavailable.
> > >>
> > >> +For Code Change actions, a committer may choose to employ assumed or
> > >> stated Lazy Approval under the [CTR](#CTR) policy. Assumed Lazy
> Approval
> > >> has no minimum length of time before the change can be made.
> > >> +
> > >>  <table>
> > >>  <tr><th>Action</th>
> > >>      <th>Description</th>
> > >>
> > >
> > >
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>

--001a11c2f0acb6bd3b04f703cc22--