Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> [DISCUSS] Define CTR in Bylaws


Copy link to this message
-
[DISCUSS] Define CTR in Bylaws
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    (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 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>

 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB