accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Bylaws Change - Majority Approval for Code Changes
Date Wed, 26 Nov 2014 20:06:10 GMT
I share Benson's concerns about a procedural change to majority vote. I see
this as somewhat of a drastic measure.

That said, the recent veto has left me in a pretty frustrated state,
because I really don't think a simple API addition that adds some minor
feature should have been that contentious, such that it warranted a veto (a
-0 at best). So, if that veto becomes precedent-setting, in terms of the
what kinds of disagreement warrants a veto, I predict many future problems
in this community. I personally set the bar pretty high for vetos (security
issues, significantly impacts usability or future development, etc.).

In short, I don't know what to do, but, in the case that initiated this
discussion, I hold out hope for a retraction of the veto, based on
reasonable discourse and compromise.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Wed, Nov 26, 2014 at 2:42 PM, Benson Margulies <bimargulies@gmail.com>
wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message