accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [DISCUSS] Define CTR in Bylaws
Date Fri, 04 Apr 2014 16:53:02 GMT
Yes, precisely.


On Fri, Apr 4, 2014 at 11:47 AM, John Vines <vines@apache.org> 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 <busbey@cloudera.com> 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 <vines@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 <busbey@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.rinaldi@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
>>
>
>


-- 
Sean

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message