accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [DISCUSS] Define CTR in Bylaws
Date Fri, 04 Apr 2014 16:58:05 GMT
+1 for the initial changes Billie proposed.


On Fri, Apr 4, 2014 at 12:53 PM, Sean Busbey <busbey@cloudera.com> wrote:

> 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