accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Corey Nolet <cjno...@gmail.com>
Subject Re: [VOTE] Accumulo Bylaws, vote 2
Date Fri, 04 Apr 2014 02:02:55 GMT
I finally got a chance to fully read through the bylaws and this email
thread.

+1 to approval for the bylaws. Thanks for writing these up!


On Thu, Apr 3, 2014 at 9:59 PM, Sean Busbey <busbey+lists@cloudera.com>wrote:

> Corey,
>
> Just for clarity, is your +1 to Benson's sentiment or to the Bylaws Vote
> for this thread?
>
> -Sean
>
>
> On Thu, Apr 3, 2014 at 8:58 PM, Corey Nolet <cjnolet@gmail.com> wrote:
>
> > +1
> >
> >
> >
> >
> > On Thu, Apr 3, 2014 at 8:45 PM, Benson Margulies <bimargulies@gmail.com
> > >wrote:
> >
> > > If you're all going to go spelunking in the Apache policy docs,
> > > perhaps I can help a bit with context.
> > >
> > > The original HTTPD project developed a very specific set of policies
> > > for controlling  _commits to the code base_. The ballet of
> > > -1/veto/justification comes out of there. The overall foundation
> > > policy is an expectation that all projects will apply that same
> > > approach to commits unless they can state a very good reason to do
> > > something else.
> > >
> > > Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto.
> > > Justification is polite, but not required. Proceeding in the face of a
> > > -1 is not always a good idea, but the policy envisions it; it
> > > envisions that someone might vote -1 because they _might prefer_ to
> > > wait for some other change. But they can just be outvoted.
> > >
> > > Once you get past commits to the codebase and releases, you're more on
> > > your own in deciding how to decide. The particular case at hand, these
> > > bylaws, is an interesting one.
> > >
> > > People should be really clear about what they mean when they propose
> > > consensus as a process. Yes, a consensus process is a process in which
> > > every member of the community has a veto. However, it is also a
> > > process in which every member of the community feels a grave weight of
> > > responsibility in using that veto. Focussing on the veto in a
> > > consensus process is not a good sign.
> > >
> > > Consensus is a slow, deliberative, process, chosen by communities
> > > which value group cohesion over most everything else. It is also a
> > > process that presumes that there is a _status quo_ which is always
> > > acceptable. The community sticks to the status quo until everyone
> > > involved is ready to accept some change. This approach to
> > > decision-making is pretty hard to apply to a new group trying to chart
> > > a new course.
> > >
> > > It is _not_ foundation policy to expect communities to choose
> > > full-blown consensus as the predominant process. Typically, in my
> > > experience, Apache projects do not do full consensus process. Instead,
> > > they strive to give everyone a voice and seek consensus, but
> > > eventually decide via a majority of some kind. Most of the time, the
> > > first part of that (open discussion) achieves a consensus, so that the
> > > second part of that becomes a formality. However, from time to time,
> > > the community chooses to decide by majority in order to decide. The
> > > touchstone of a healthy community is that the minority feel heard and
> > > not steamrolled.
> > >
> >
>

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