+1 for the initial changes Billie proposed.
On Fri, Apr 4, 2014 at 12:53 PM, Sean Busbey <[email protected]> wrote: > Yes, precisely. > > > On Fri, Apr 4, 2014 at 11:47 AM, John Vines <[email protected]> wrote: > > > 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 > >> > > > > > > > -- > Sean >
