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 (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 stated or assumed, 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>
Good point. I've fixed it. On Mon, Apr 14, 2014 at 10:10 AM, Bill Havanki <[EMAIL PROTECTED]>wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext