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?
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, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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:
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 <[EMAIL PROTECTED]> 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:
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 <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> wrote:
Can the discussion be tabled for 48 hours to allow the holiday and the Northeastern snowstorm to pass? I can understand the frustration, for different reasons, on both sides of this issue. Asking for quick responses seems to be increasing the irascibility of people. Is there a procedure to extend the deadline ... or to restart the vote at a later date?
FYI, no one is suggesting removing anyone from PMC. I was just citing the bylaws with regards to vetos. Sorry if this caused confusion.
P.S. We have a *very* polite and pleasant crowd. Since 1987 I have been involved with a lot of open-source projects and I haven't seen anything in this project that I would call contentious :-) On Wed, Nov 26, 2014 at 03:13:50PM -0500, David Medinets wrote:
A veto is the beginning of a discussion of a change, not the end, in stock Apache practice.
On Wed, Nov 26, 2014 at 3:21 PM, Jeremy Kepner <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext