incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [RESULT][VOTE] Apache Gearpump (incubating) 0.8.1-RC3
Date Mon, 18 Jul 2016 22:59:04 GMT
On Mon, Jul 18, 2016 at 3:20 PM, Justin Mclean <justin@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message