community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <orc...@apache.org>
Subject RE: Vetoes for New Committers??
Date Wed, 29 Mar 2017 16:14:21 GMT


> -----Original Message-----
> From: Marvin Humphrey [mailto:marvin@rectangular.com]
> Sent: Wednesday, March 29, 2017 05:13
> To: dev@community.apache.org
> Subject: Re: Vetoes for New Committers??
> 
[ ... ]
> 
> Most PMCs do not draft their own rules, and just use "at least 3 +1
> with no vetoes". CouchDB's majority-rule for committers is unusual. I
> hope that CouchDB's bylaws are not adopted as a template for others,
> as I believe that the rule on committer voting is counter to an
> important institutional tradition in Apache governance.
> 
[ ... ]
[orcmid] 

I think there are common misunderstandings about where vetoes are allowed (as opposed to No
votes that need to be addressed as part of consensus-seeking and community cultivation).

My understanding is that votes on *procedural*matters* have no vetoes by default, but the
effort to achieve consensus is always important in the presence of Nays.  Treating nays as
vetoes is often inappropriate because it admits a form of bull-dozing in the negative.  Note
that lazy consensus is a form of unanimous consent, with no explicit requirement for 3 +1s;
 here an objection is not a veto since lazy consensus is specifically an if-no-objection proposal
and objections are invited.

The only firm veto seems to be on commits.  And, of course, the 3 +1s majority is *specifically*
for eligible votes on release candidates (and which cannot be vetoed).

The veto business (and the 3 +1s) seem to leak all over PMC practice without ever being made
an explicit policy as some sort of urban legend.  The fact that a podling mentor can veto
actions (and also claim the myths as policy) is probably confusing in that regard (if that
is still the IPMC practice).

 - Dennis


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org


Mime
View raw message