accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: [DISCUSS] Define CTR in Bylaws
Date Fri, 04 Apr 2014 16:36:56 GMT
+1 when the description is crafted to fit the prevailing CtR practice.


On Fri, Apr 4, 2014 at 12:35 PM, <dlmarion@comcast.net> 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" <busbey@cloudera.com>
> To: "dev@accumulo apache. org" <dev@accumulo.apache.org>, vines@apache.org
> 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 <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
>
>


-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

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