accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Corey Nolet <cjno...@gmail.com>
Subject Re: [DISCUSS] Bylaws Change - Majority Approval for Code Changes
Date Wed, 26 Nov 2014 18:42:06 GMT
Jeremy,

The PMC boards in ASF are re

On Wed, Nov 26, 2014 at 1:18 PM, Jeremy Kepner <kepner@ll.mit.edu> wrote:

> To be effective, most boards need to be small (~5 people) and not involved
> with day-to-day.
> Ideally, if someone says "let's bring this to the board for a decision" the
> collective response should be "no, let's figure out a compromise".
>
> On Wed, Nov 26, 2014 at 12:26:09PM -0600, Mike Drob wrote:
> > Jeremey, FWIW I believe that the PMC is supposed to be that board. In our
> > case, it happens to also be the same population as the committers,
> because
> > it was suggested that the overlap leads to a healthier community overall.
> >
> > On Wed, Nov 26, 2014 at 12:02 PM, Jeremy Kepner <kepner@ll.mit.edu>
> wrote:
> >
> > > -1 (I vote to keep current consensus approach)
> > >
> > > An alternative method for resolution would be to setup an
> > > elected (or appointed) advisory board of a small number of folks whose
> > > job it is to look out for the long-term health and strategy of
> Accumulo.
> > > This board could then
> > > be appealed to on the rare occassions when consensus over important
> > > long-term issues
> > > cannot be achieved.  Just the presence of such a board often has the
> effect
> > > encouraging productive compromise amongst participants.
> > >
> > >
> > >
> > > On Wed, Nov 26, 2014 at 05:33:40PM +0000, dlmarion@comcast.net wrote:
> > > >
> > > > It was suggested in the ACCUMULO-3176 thread that code changes
> should be
> > > majority approval instead of consensus approval. I'd like to explore
> this
> > > idea as it might keep the voting email threads less verbose and leave
> the
> > > discussion and consensus building to the comments in JIRA. Thoughts?
> > >
>

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