This vote will be open for 7 days, until 4 April 2014 14:00 UTC.
Upon successful completion of this vote, the first line of the document body will be replaced with "This is version 1 of the bylaws," and the statement defining the document as a draft will be stricken. Additionally, a link to the document will be added to the navigation menu.
This vote requires majority approval to pass: at least 3 +1 votes and more +1 than -1's.
[ ] +1 - "I approve of these proposed bylaws and accept them for the Apache Accumulo project." [ ] +0 - "I neither approve nor disapprove of these proposed bylaws, but accept them for the Apache Accumulo project." [ ] -1 - "I do not approve of these proposed bylaws and do not accept them for the Apache Accumulo project because..."
The way I'm reading actions, all code changes must be presented at least one day before they can be committed. Is that intended this way? On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <[EMAIL PROTECTED]> wrote:
On Tue, Apr 1, 2014 at 12:46 PM, John Vines <[EMAIL PROTECTED]> wrote: I wasn't reading it that way. Code change is lazy approval, and "An action with lazy approval is implicitly allowed unless a -1 vote is received." Not requiring a vote supersedes the minimum vote length. In the event of falling back to consensus approval for code change, the minimum vote length is 1 day.
The only time there is more than one type of approval (not vote) required is when the first one is lazy consensus, which doesn't actually require a vote. Maybe we just need some elaboration on how to CTR which is referenced from this doc ("Please refer to the Accumulo commit and review standard for details")? On Tue, Apr 1, 2014 at 1:17 PM, John Vines <[EMAIL PROTECTED]> wrote:
The only two places we have a lazy falling back to another type of vote is code change and release plan. For release plan, I interpret the minimum length to apply to either type of vote. However, you're stating that this is not the case for a code change. So there is ambiguity about minimum length applying to lazy approvals that needs to be cleared up here. On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <[EMAIL PROTECTED]>wrote:
As part of getting us a (literally) passable first set of bylaws as a foundation, at one point I "refactored" the commit and review details out to an as-yet-to-be-written standard. So, what is in the bylaws should be interpreted as permissive.
My interpretations: A "code change" can certainly be a commit - "a change made to a codebase of a project". Lazy approval is based on that commit. The minimum voting period (here and for release plan) applies to both vote phases separately, so *n* days for lazy approval, *n* days for consensus if needed. (I imagine lazy approval has some period since getting a veto one month later shouldn't be possible, for example; but if that doesn't make sense, never mind. :) )
I have all sorts of ideas about the commit and review details, and I bet others do too, which is why I like having that split off from getting some version 1 bylaws in place. As the policies evolve, we still have the option to modify the bylaws as needed.
Bill On Tue, Apr 1, 2014 at 4:40 PM, John Vines <[EMAIL PROTECTED]> wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
I think the problem is that we're actually dealing with two flavors of lazy consensus, one where you explicitly state "if no one disagrees by X then I'm doing Y," and another where you do Y, and assume it is approved if no one objects. For the former, you need some kind of minimum length to announce. But for the latter, which is what happens under CTR, a length doesn't make sense. ASF documentation is not entirely clear on this distinction (the examples of lazy consensus are all of the first type, but it also says that CTR is an application of decision making through lazy consensus). That's why I think a good description of CTR would resolve the issue. On Tue, Apr 1, 2014 at 1:40 PM, John Vines <[EMAIL PROTECTED]> wrote:
So every single potential commit needs to pass a 1 day lazy consensus vote before it can be pushed. This is the issue I have with the current wording. On Tue, Apr 1, 2014 at 5:15 PM, Bill Havanki <[EMAIL PROTECTED]>wrote:
I do not like this. It sounds like I can veto a release by putting a veto on a commit, when we explicitly state that release votes are majority, not consensus. On Tue, Apr 1, 2014 at 2:20 PM, Billie Rinaldi <[EMAIL PROTECTED]>wrote:
There is still no clarity on code change actions, which I think need to be resolved before it should pass. It seems to be ambiguous, intentionally, with the intent to revise later. If that's the case, it should just be removed until a more definitive guideline can be put in place. Or just point at an existing CTR guideline. On Thu, Apr 3, 2014 at 2:18 PM, Bill Havanki <[EMAIL PROTECTED]>wrote: Cheers ~John
I'm also wondering if modifying bylaws, for now and in the future, should be consensus approval. Why is that scaled down to Majority? On Thu, Apr 3, 2014 at 3:13 PM, John Vines <[EMAIL PROTECTED]> wrote:
Re-reading this section of the proposed guidelines does give me pause as it's not straightforward and can appear counter to what our "commit guidelines" (ctr presently) are.
Changing my vote to +0 for now. I'd like to see some plan that at least addresses it before moving forward. Seems silly to release a first round of bylaws that we aren't all in agreement about, but, at the same time, I can appreciate the pain getting a 7-day vote passed brings...
Unfortunately, I think I'm going to have to change my vote to a -1, based on the point that John just brought up.
After some thought, I'm not sure it makes sense for people to be bound by operating rules they did not agree to, especially for the initial adoption. I think consensus approval makes more sense for modifying the bylaws (and for the initial adoption of those bylaws) than does majority approval.
I dug into the dev archives for how the approval definition got set. Originally, from the ZooKeeper bylaws , modification required 2/3 majority of ALL PMC members to +1 in order to pass. Billie didn't prefer that since it isn't an ASF-defined vote, and suggested consensus  (February 26).
I didn't like that and preferred majority since (surprise!) I didn't like the idea of a veto. I preferred majority approval. [next in thread after 2] Billie said she was neutral about that [second in thread after 2]. So, I set it to majority approval and said anyone can switch it to consensus, that would be fine  (March 4). No one changed it. So, here we are.
The ASF voting guidelines  only discuss vetoes in the context of code modification. Its section on Procedural Votes is unhelpfully empty. However, at the top it says:
Votes on procedural issues follow the common format of majority rule unless otherwise stated. That is, if there are more favourable votes than unfavourable ones, the issue is considered to have passed -- regardless of the number of votes in each category. (If the number of votes seems too small to be representative of a community consensus, the issue is typically not pursued. However, see the description of lazy consensus for a modifying factor.) When I called this vote, I decided that since the bylaws stated majority approval for modifications, the vote should be majority approval. There was time for the community to deliberate about it before the vote, so absent any concern (that I recall seeing) it was the consistent choice. (In fact, the first vote Mike called on March 10 was also majority approval.)
That is my rationale for majority approval in this vote.
<opinion owner="bill_h" validity="dubious"> Voting is not a substitute for deliberation, working as a group to generate agreement on decisions. First, those involved get together and hash out the details, and then at some point there is a vote on the outcome of those deliberations. (Unless you're Congress. ZING) Deliberation can take a long time ... a really long time. And it's not usually fun. At some point you just must call it.
I don't like consensus approval for bylaw changes because someone could torpedo the vote and ruin the extensive work that went into getting there. It can actually discourage being involved in the deliberative process, because you could always just jump in at the vote time and veto, either for a well thought-out reason or just because. That's not fair to everyone who spent lots of time deliberating, compromising, exploring. (Harshness warning.) If you really had an issue, you should have brought it up before the vote was called so the community could spend proper time on it. Voting time isn't the appropriate time to discover fundamental issues with what you're voting on.
Also, in life, you don't always get what you want, and you don't always get it perfect the first time. Majority approval lets a group get something good enough, even with some problems and disagreement, started, or progressing. You can then begin a new round of deliberations, and vote on modifications to make it even better.
Even if that modification is changing to consensus approval for bylaw changes. </opinion>
If the XML tag wasn't signal enough, this is really my opinion. Part of this is working out, as a community, how we make decisions, so you should certainly form your own opinion and apply it to the current vote and future ones. On Thu, Apr 3, 2014 at 4:29 PM, Mike Drob <[EMAIL PROTECTED]> wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
On Thu, Apr 3, 2014 at 4:57 PM, Bill Havanki <[EMAIL PROTECTED]>wrote: No one should be able to veto "just because". A veto should have a defensible reason. Also if someone is not willing to defend their veto, is it valid? If someone votes -1 and never answers questions about their position, can that vote be ignored?
To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, *etc.* ). A veto without a justification is invalid and has no weight.
So an individual already cannot veto "just because" and must provide a reason. From our bylaws:
A valid, binding veto cannot be overruled. If a veto is cast, it must be accompanied by a valid reason explaining the veto. The validity of a veto, if challenged, can be confirmed by anyone who has a binding vote. This does not necessarily signify agreement with the veto, but merely that the veto is valid.
If you disagree with a valid veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, the action that has been vetoed must be reversed in a timely manner.
So it looks like we've got that part covered. Further, from the ASF glossary on veto According to the Apache methodology, a change which has been made or proposed may be made moot through the exercise of a veto by a committer to the codebase <http://www.apache.org/foundation/glossary.html#Codebase> in question. If the R-T-C<http://www.apache.org/foundation/glossary.html#ReviewThenCommit>commit policy is in effect, a veto prevents the change from being made. In either the R-T-C or C-T-R<http://www.apache.org/foundation/glossary.html#CommitThenReview>environments, a veto applied to a change that has already been made forces it to be reverted. Vetos may not be overridden nor voted down, and only cease to apply when the committer who issued the veto withdraws it. All vetos *must* be accompanied by a valid technical justification; a veto without such a justification is invalid; in case of doubt, deciding whether a technical justification is valid is up to the PMC. Vetos force discussion and, if supported, version control rollback or appropriate code changes. Vetoed code commits are best reverted by the original committer, unless an urgent solution is needed (e.g., build breakers). Vetos only apply to code changes; they do not apply to procedural issues such as software releases.
Based on this, a veto can only be applied to code, not to process. Changing the bylaws is a matter of process, not code, and I feel that it should be majority for consistency with the rest of the ASF.  https://www.apache.org/foundation/voting.html#Veto
By those glossary definitions, we're misusing veto throughout the majority of our bylaws, so we need to rewrite them to clarify the terminology, either by rewording it to not use veto or to redefine veto for our project. On Thu, Apr 3, 2014 at 5:28 PM, Mike Drob <[EMAIL PROTECTED]> wrote:
On Thu, Apr 3, 2014 at 1:57 PM, Bill Havanki <[EMAIL PROTECTED]>wrote: Going by the standards of a release vote, voting is actually the appropriate time to discover fundamental issues. That's kind of the whole point of voting -- getting people to agree that there are no fundamental issues with what you're voting on. Finding valid, justifiable issues should be welcome, as it results in a better product, whether the product be a release or a community standard.
Given that we already have a couple of departures from ASF definitions in our proposed bylaws, I think changing bylaws votes to Consensus Approval would be more in line with our community practices. In particular, I would not feel good about the current vote passing, despite the fact that at the moment it meets the criteria of Majority Approval.
On Thu, Apr 3, 2014 at 5:14 PM, Billie Rinaldi <[EMAIL PROTECTED]>wrote:
As an aside, this is not encouraged in our current release process.
The test practices for a release take longer than the voting period for an RC. This directly implies that the fundamental issues must have been worked out prior to a call to vote.
I've been fine with this interpretation, largely because it lines up with Apache guidelines around votes: do the consensus building work up front. If we're going to use a release vote as a time to do primary vetting, then we should probably change our RC vote window.
<opinion owner="billh" validity="possibly_more_dubious"> I disagree that a limited-time vote is an appropriate time to find a fundamental issue in what's being voted on. The effort leading up to the vote should have been well-known, and if you care, you should be involved then, doing your own assessments and working with others, having ample time to do so. Sure, sometimes, a truly horrible, unforeseen problem can surface after all that work. When that happens, everyone should vote against so the vote fails. You would hope that is rare, though.
The time to forge agreement is before the vote, in deliberations, so the product voted upon is the fruit of that. With this bylaw effort, sadly, I observe that more attention is being paid to the bylaw effort at vote time and not before, so I suppose my viewpoint isn't widely shared. (Sorry, harshness warning.) It would, however, explain how this process is so difficult now.
I don't see where we are misusing or misdefining "veto" in the bylaws. We did, during deliberations, work to harmonize the bylaws with ASF standards, e.g., eliminating undefined approval types like 2/3 majority, better defining PMC responsibilities, getting emeritus status and access removal standards right. I don't recall any problem with veto being raised. </opinion>
Now as vote caller (to all):
If the bylaws in their current state are so unacceptable to you that you would not be comfortable with them passing, then you should definitely vote -1, especially as opposed to a +0 or -0. The current tally is +5 to -2, so it is defeated by +1 voters switching, and/or others voting -1.
Also, if you haven't voted yet ... VOTE!
I will state just once more that the bylaws provide for amending, so passage of this vote does not obstruct improvements, corrections, and clarifications afterwards.
My tank is empty, and I've written way too much, so I bow out of this discussion until the vote closes. On Thu, Apr 3, 2014 at 6:14 PM, Billie Rinaldi <[EMAIL PROTECTED]>wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
On Thu, Apr 3, 2014 at 3:37 PM, Sean Busbey <busbey+[EMAIL PROTECTED]>wrote: Our disagreement here might largely be due to differing definitions of "fundamental issues." Also, I think you might be blocking out what happened between the first 1.5.0 release candidate and the last? =)
While I think the bylaws are fine as is, and I think future issues can be fixed through follow on amendments, there are clearly issues that have not been resolved. I would like to see strong adoption for the first pass, and then majority for future issues. On Thu, Apr 3, 2014 at 3:57 PM, Billie Rinaldi <[EMAIL PROTECTED]>wrote:
Could the -1 voters please explain what we can't fix with a follow on modification to the bylaws after this vote?
Even on the matter of consensus vs majority approval for bylaw modifications, it is relatively easy for a follow on vote to make this change. It is no more difficult, say, than starting another vote after this one fails. Certainly, it is easier than the reverse transition would be.
On Thu, Apr 3, 2014 at 6:43 PM, Mike Drob <[EMAIL PROTECTED]> wrote:
If you're all going to go spelunking in the Apache policy docs, perhaps I can help a bit with context.
The original HTTPD project developed a very specific set of policies for controlling _commits to the code base_. The ballet of -1/veto/justification comes out of there. The overall foundation policy is an expectation that all projects will apply that same approach to commits unless they can state a very good reason to do something else.
Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto. Justification is polite, but not required. Proceeding in the face of a -1 is not always a good idea, but the policy envisions it; it envisions that someone might vote -1 because they _might prefer_ to wait for some other change. But they can just be outvoted.
Once you get past commits to the codebase and releases, you're more on your own in deciding how to decide. The particular case at hand, these bylaws, is an interesting one.
People should be really clear about what they mean when they propose consensus as a process. Yes, a consensus process is a process in which every member of the community has a veto. However, it is also a process in which every member of the community feels a grave weight of responsibility in using that veto. Focussing on the veto in a consensus process is not a good sign.
Consensus is a slow, deliberative, process, chosen by communities which value group cohesion over most everything else. It is also a process that presumes that there is a _status quo_ which is always acceptable. The community sticks to the status quo until everyone involved is ready to accept some change. This approach to decision-making is pretty hard to apply to a new group trying to chart a new course.
It is _not_ foundation policy to expect communities to choose full-blown consensus as the predominant process. Typically, in my experience, Apache projects do not do full consensus process. Instead, they strive to give everyone a voice and seek consensus, but eventually decide via a majority of some kind. Most of the time, the first part of that (open discussion) achieves a consensus, so that the second part of that becomes a formality. However, from time to time, the community chooses to decide by majority in order to decide. The touchstone of a healthy community is that the minority feel heard and not steamrolled.
I don't know that the consensus vs. majority issue is fixable ex post facto... by establishing these bylaws, we're basically binding everybody in the community to a set of rules that is not in full agreement (with majority approval). Binding those who disagree to the rule that it is okay to proceed in spite of their disagreement seems a bit authoritarian. I understand that the initial vote was following the rules in the content of what was being voted on... and that makes sense to me, and I agree with it. However, given my concerns about binding dissenters to the same rules, with the sensible goal of using the established rules for establishing those same rules, it seems to me that full consensus is the only option that makes sense.
If there were no other outstanding issues, I would say that we could move past this and change to consensus for modifying bylaws later... but then we're going to revisit this same chicken/egg problem then, but in a weird way: we'd be using majority voting to change to consensus voting. If there's minority dissent at that point, it'd still pass, but only by enacting a rule that would not have passed had the newly applied rule been in place. It seems to me that full consensus for initiating or modifying bylaws is the only sensible and internally consistent mechanism for voting on the bylaws themselves.
The other issue, regarding clarification of wording around code changes I think can be fixed later.
Personally, while not voting -1, I still don't quite agree that pushing the first draft of a document to a successful vote that has dissent from more than one PMC member.
To my knowledge, there is no rush to release such a document, so it doesn't make sense to me to release such a document to just turn around and make an amendment to it. Let's get it right the first time and not set a precedent for ignoring the concerns. Community comes first.
Presently, my biggest concern is that there is still some ambiguity about the lazy approval of code changes that John initial brought up. I haven't thought enough about the majority versus consensus rules, but my first impression is, that with good faith, this isn't a big concern that needs to be hashed up front.
Lastly, I want to applaud Bill for stepping up to spearhead this. The frustration with this process, akin to that which we face for every release, is unavoidable. No, the community as a whole does not always (ever?) read everything up front, and that is the difficulty in working as a group. However, I do not feel like just because someone missed the "preferred" time window to voice a concern means that those concerns are no longer valid at the given moment. Just as we wouldn't treat an issue found in an RC during the last hour of the vote differently than an issue found before the RC was made (everyone would much rather the latter always be the case), discussion that was raised late in the game is just as important as discussion raised before the approval vote.
I don’t see the need to push something through that it sounds like we know we’re going to change immediately, especially given that there is opposition to the proposed bylaws. What’s the down side of waiting to get it right now?
I do second Josh’s comments. Thanks Bill and everyone else for the hard work on this! On Apr 4, 2014, at 12:03 AM, Josh Elser <[EMAIL PROTECTED]> wrote:
Changing my vote to -0. I am personally neutral on whether we alter the document before changing its version number or vice versa, but there appears to be (informal) majority approval for fixing first.
Regarding Christopher's comments, I think that using majority approval to vote to change to consensus approval is internally consistent -- the people who vote against believe in majority approval, so they should be okay with the vote passing. It's the other direction that has problematic logic. On Thu, Apr 3, 2014 at 8:15 PM, Christopher <[EMAIL PROTECTED]> wrote:
The majority approval vote on version 1 of the bylaws passes. Because of the extensive discussion and vote changes, I will list each voter's final vote below. Please verify that my list is correct based on the vote's history prior to 1400 UTC (10 AM EDT / 7 AM PDT) today.
I will update the bylaw doc to version 1 and remove the draft statement. I will also fix the link that Sean found early on. Based on the vote history, and if there is no objection, I will also add to the doc (replacing the draft statement):
Community work actively continues on the bylaws, and so key segments of them are subject to change. Thank you to everyone who voiced their opinions and voted.
Bill H On Fri, Apr 4, 2014 at 9:20 AM, Billie Rinaldi <[EMAIL PROTECTED]>wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283