Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 27C3B10BB3 for ; Mon, 7 Apr 2014 14:35:02 +0000 (UTC) Received: (qmail 50566 invoked by uid 500); 7 Apr 2014 14:35:01 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 50526 invoked by uid 500); 7 Apr 2014 14:35:00 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 50516 invoked by uid 99); 7 Apr 2014 14:34:59 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2014 14:34:59 +0000 Received: from localhost (HELO mail-la0-f51.google.com) (127.0.0.1) (smtp-auth username ctubbsii, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2014 14:34:58 +0000 Received: by mail-la0-f51.google.com with SMTP id pv20so4768990lab.24 for ; Mon, 07 Apr 2014 07:34:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.52.104 with SMTP id s8mr20688177lbo.7.1396881296614; Mon, 07 Apr 2014 07:34:56 -0700 (PDT) Received: by 10.114.96.138 with HTTP; Mon, 7 Apr 2014 07:34:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Apr 2014 10:34:56 -0400 Message-ID: Subject: Re: [VOTE] Define CTR in Bylaws From: Christopher To: Accumulo Dev List Content-Type: text/plain; charset=UTF-8 +1 -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Apr 7, 2014 at 10:11 AM, Billie Rinaldi 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. > > + > +## 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 @@ > Majority Approval > A majority approval vote passes with 3 binding +1 votes and more > binding +1 votes than -1 votes. > Lazy Approval (or Lazy Consensus) > - 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. > + 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 stated or assumed, as detailed on the [lazy > consensus page](http://accumulo.apache.org/governance/lazyConsensus.html) > . > > > ## 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. > + > > >
ActionDescription