I wonder, when voting in new ASF Members is there the discussion on each nominee to achieve consensus...
Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Wed, Mar 29, 2017 at 6:14 PM, Dennis E. Hamilton <orc...@apache.org> wrote: > > > > -----Original Message----- > > From: Marvin Humphrey [mailto:mar...@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-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
