On Mon, Jul 18, 2016 at 3:20 PM, Justin Mclean <jus...@classsoftware.com> wrote:
> > 4. Veto rule differences (or lack thereof) within the general@ voting > vs dev@<podling> voting > > Releases can not be vetoed [3], a -1 is not a veto. 3 +1 are required and > more +1s than -1s. Typically what happens in a smooth functioning project is that if somebody points out a heinous problem (forgot to include the source code in a source release, say), everybody (or nearly everybody) who previously voted +1 will immediately change their vote to -1 for the release. But it should be emphasized that there is a rather confusing overlay here of formality and informality at Apache. There is some very strict formality, for instance, about getting the intellectual property issues of releases very, very correct. This is foreign to most new incubation projects and takes time to get used to. On the other hand, votes are best viewed as a way to record consensus rather than a way to make decisions. This is much more informal in many ways than people expect after they see the rigor on IP. The thesis is that votes used as decisions might as well be bludgeons for coercing a minority interest. As such, votes as decision machines can easily be very divisive and often lead to factionalization in a project. In a smooth-running Apache project, votes just record decisions that have already been made. With this cultural context in mind, you can see why a single -1 in a release vote can unroll the entire release if it is a surprise. A tight project will generally view the surprising appearance of a -1 vote as a serious bug in consensus and it isn't uncommon for several +1 votes to flip in response in order to allow time for the consensus to be mended. The wish to register a protest vote without breaking consensus is the rationale for the -0 vote. Lots of projects don't work this well and I doubt that any project always works this well. But when this works, it is really nice. Definitely something to aspire to. Note that this also explains a bit about why the "rules" about how to conduct a vote are a bit ambiguous. Basically, if you have to read the rules really carefully to understand how a vote came out, it is best to back out of the vote itself and focus a bit on community building rather than reading rulebooks. That means that the edge cases shouldn't be important to you.
