Based on the actions table, consensus
On Fri, Apr 4, 2014 at 1:06 PM, Keith Turner <ke...@deenlo.com> wrote: > On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi <billie.rina...@gmail.com > >wrote: > > > This is a proposal to adequately describe our Commit-Then-Review process > in > > the bylaws. I have made an initial suggestion below. If we can agree on > > how to make this clarification, presumably this change would be made > > instead of removing the Code Change action from the bylaws (or would > > involve adding Code Change back in, if it happens that that change has > > already taken place). > > > > > > 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 must 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> > > > > If there is a commit and then a -1, is consensus or majority needed to > avert a revert? > > > > </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> > > >
