+1 I don't think that we need to cover all situations in the bylaws in the early versions. We can amend as situations arise.
----- Original Message ----- From: "Sean Busbey" <bus...@cloudera.com> To: "dev@accumulo apache. org" <dev@accumulo.apache.org>, vi...@apache.org Sent: Friday, April 4, 2014 12:29:48 PM Subject: Re: [DISCUSS] Define CTR in Bylaws I've spent some time dealing with hostiles in internet communities. Based on my experience, I would strongly recommend against gearing our bylaws towards guarding against actors we disagree with. 1) It presumes a conflict oriented community 2) It presumes we will have community members acting maliciously 3) It presumes any guard we come up with would ultimately work The fact of the matter is that if we are unfortunate enough to have someone who wants to be disruptive, they will find a way to be disruptive. Defining more elaborate rulesets to try to constrain them will ultimately only result in giving them more ammunition to work with. It is generally best to provide a reasonably loose set of community standards and then rely on the communities shared interest. -Sean On Fri, Apr 4, 2014 at 11:19 AM, John Vines <vi...@apache.org> wrote: > In the bylaw discussion, we had discussed the potential for someone to > reject a commit as a method to reject a release. Is this something that we > want to guard against with every release (if possible, we may need to > provide this ability in the bylaws) or should there be language in our > definitions to handle it? > > > On Fri, Apr 4, 2014 at 12:15 PM, Sean Busbey <bus...@cloudera.com> wrote: > > > As previously stated, I like this proposed change and would vote in favor > > of it. > > > > > > On Fri, Apr 4, 2014 at 11:12 AM, 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> > > > </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> > > > > > > > > > > > -- > > Sean > > > -- Sean
