+1 when the description is crafted to fit the prevailing CtR practice.
On Fri, Apr 4, 2014 at 12:35 PM, <[email protected]> wrote: > +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" <[email protected]> > To: "dev@accumulo apache. org" <[email protected]>, [email protected] > 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 <[email protected]> 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 <[email protected]> > 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 < > > [email protected] > > > >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 > > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
