community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <>
Subject Re: Veto! Veto?
Date Sat, 21 Mar 2015 22:58:30 GMT
On Sat, Mar 21, 2015 at 8:50 AM, Pierre Smits <>

> I am not talking about the consensus aspect in the principles of the ASF.
> Everybody agrees that it is (one of) the first and foremost principle(s) of
> the ASF. And I expect, like everybody else, that every contributor works
> towards that in any of the projects (and podlings) in any kind of
> situation.
> But it happens that sometimes consensus can't be reached and a vote must be
> called. And then a veto doesn't help the project to move forward.

I think that you are looking at the voting process very differently than
many others in this discussion.  In Apache communities that I have been
involved with, a vote is not something that is used to force the community
into action.  At least, it isn't something that I have seen used

If a community is seriously wedged, then you have to deal with that
problem.  Simply cramming a majority view down the throats of a minority as
a result of a vote will not have positive outcomes.

> Collegiality and community sense is a two way street.
> When a (greater) number of people within a project can collaborate with the
> 'difficult' newcomer, why should it then be possible that the one (or the
> few) with veto power - who don't/doesn't seem to be able to collaborate
> with the 'difficult' newcomer -  can block voting regarding onboarding as
> committer or PMC member?

I should like to point out that those with superior technical or people
skills are, by definition, a minority.  Moreover, those without superior
skills are typically unable to assess these skills (the so-called
Dunning-Kruger effect which is not at all connected to me).

These facts make me very inclined to try to listen to minority voices.  I
am often unsuccessful, but I have seen a very high correlation between not
listening to these and failing in my own personal history.

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