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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB