accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: [DISCUSS] Bylaws Change - Majority Approval for Code Changes
Date Wed, 26 Nov 2014 19:42:08 GMT
Writing as an ASF member and at least emeritus or perhaps active (I
can't recall) member of this PMC, I would be very concerned if we felt
the need to move to some sort of majority voting scheme.

A healthy community does not suffer from such a volume of disagreement
about technical direction that it needs to be voting on very many
changes, let alone needing a majority voting scheme to resolve
irreconcilable differences. Vetos, in the usual Apache scheme of
things, should be _rare_ events.

In  RTC communities, sometimes changes take a long time to get to C if
they are controversial. A procedural short-cut to a majority isn't
fixing the problem, which is lack of consensus over direction, it's
hiding it.

I confess that I was not tuned into the start of all this; I strongly
recommend a rewind to the question of why there are enough
disagrements to motivate this proposal.


On Wed, Nov 26, 2014 at 2:11 PM, Jeremy Kepner <kepner@ll.mit.edu> wrote:
> Accoding to ASF bylaws a valid veto from a PMC member is binding.
> Also, there is no procedure for throwing someone off the PMC.
> So such a veto is binding for as long as the PMC member maintains their status.
>
> Most companies appoint 3,5,7 person majority rule boards that are not involved
> with day-to-day to allow consensus for day-to-day operations, but
> provide a relief valve when consensus cannot be achieved over important
> decisions.  The existence of a board induces compromise since an individual
> veto is unlikely to hold up when brought to the board.
>
> On Wed, Nov 26, 2014 at 01:45:48PM -0500, Corey Nolet wrote:
>> Jeremy,
>>
>> The PMC boards in ASF are required to look out for the long term health of
>> the entire project. This is why the conversation of consensus can be a
>> touchy one and a hard one to agree on. If a single PMC member vetos a code
>> change, can that single member stop the code from being changed or could
>> majority overrule the veto. It's going to be a complicated discussion.
>>
>> On Wed, Nov 26, 2014 at 1:42 PM, Corey Nolet <cjnolet@gmail.com> wrote:
>>
>> > 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
View raw message