That makes sense, Sean. So are you saying that you think it's best to include no language whatsoever to enable restricting CtR vetoes during a release?
On Fri, Apr 4, 2014 at 12:29 PM, Sean Busbey <[email protected]> wrote: > 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 >
