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 <bimargul...@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 <kep...@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 <cjno...@gmail.com> wrote: > >> > >> > Jeremy, > >> > > >> > The PMC boards in ASF are re > >> > > >> > On Wed, Nov 26, 2014 at 1:18 PM, Jeremy Kepner <kep...@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 <kep...@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, dlmar...@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? > >> >> > > > >> >> > >> > > >> > >
