community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Veto! Veto?
Date Sat, 21 Mar 2015 16:34:26 GMT
Can someone please link to any place where invitation of committers and of PMC members is subject
to a veto (as opposed to a need to see if -1 objections can be cured in discussion of the
objection) as a matter of policy?

[One case is that PMC invitations are subject to Board lazy consensus, but that is after the
recommendation goes forward from the PMC, and PPMC policy might be different with requirements
for mentor concurrence.  I am not asking about those.]

Here is where I see it, <http://www.apache.org/foundation/glossary.html#Veto>.  I presume
invitation of committers and PMC members is a procedural issue in this context even when a
formal vote is required/conducted).

-----Original Message-----
From: Pierre Smits [mailto:pierre.smits@gmail.com] 
Sent: Saturday, March 21, 2015 08:50
To: dev@community.apache.org
Subject: Re: Veto! Veto?

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.

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?

Best regards,


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Mar 21, 2015 at 4:34 PM, Pierre Smits <pierre.smits@gmail.com>
wrote:

> Majority voting, regarding on and offboarding of people, is less subject
> of abuse - when it comes to get to a resolution -  than the veto mechanism.
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sat, Mar 21, 2015 at 4:26 PM, jan i <jani@apache.org> wrote:
>
>> On 21 March 2015 at 15:24, Pierre Smits <pierre.smits@gmail.com> wrote:
>>
>> > Again, this is not about the veto mechanism for the technical works of
>> the
>> > project. This is about onboarding of new people, this is about community
>> > development.
>> >
>> > Voting is not a technicality or formality when it comes to people. It is
>> > the ultimate means to get to a resolution. We can discuss all we want,
>> but
>> > there are times when discussing doesn't lead to some kind of resolution
>> > (consensus or implicit acceptance). When the discussion heats up, it
>> often
>> > leads to 'I am right and you are wrong' to and fro. When that happens
>> > voting will bring a resolution. But then a veto is the ultimate 'my way
>> and
>> > I won't budge' variant in stead of seeking the compromise. In the case
>> of
>> > people (both onboarding and offboarding) it doesn't help to move a
>> project
>> > forward. It is a postponer, a show stopper.
>> >
>> > In a posting above it said that the PMC of a project is free to define
>> it
>> > own ruleset regarding the way that project operates. But that freedom is
>> > bound by the principles of the Apache Software Foundation. Principles
>> (and
>> > changes thereon) that are voted upon by the members of the ASF. This
>> > platform is the place to discuss the aspects of community development
>> in a
>> > broader sense. Like we did when the topic of the project maturity model
>> > came up. This is another topic in that broader sense of building mature
>> > projects.
>> >
>> you are right this is the platform to discuss these matters, but you are
>> wrong that there is
>> a policy or principle that the vote for new committers/need to allow a
>> veto.
>>
>> What you refer to is a recommendation ! Is you follow projects you will
>> from time to time
>> see projects forward a suggested PMC extension to the board (Board has to
>> acknowledge
>> every PMC extension, with a 72 hour delay) without having had a vote, but
>> just refer to
>> a consensus thread.
>>
>> So I do not understand the problem, if your PMC wants not to include veto
>> in PMC/Committer go
>> ahead and do so. My personal opinion (my policy or ...) is that if a PMC
>> have had a discussion and then
>> someone gives a -1 in the vote, there is a community problem not a policy
>> problem.
>>
>>
>> >
>> > Why the need to talk specifics? This is not about finger pointing or
>> naming
>> > and shaming. And if it were, it shouldn't be done here but in a private
>> > message to the board. And I trust that the board has ample means to take
>> > appropriate actions.
>> >
>> Sorry it was not to offend you, but simply to get a better understanding
>> of
>> what the problem really is,
>> as said above if your PMC does not like veto then donĀ“t use it, nobody
>> forces you to use it.
>>
>> If the problem is you want to change the recommendation, then it might be
>> a
>> good idea to talk about a
>> specific change to a specific page.
>>
>> rgds
>> jan I.
>>
>>
>> >
>> > Best regards,
>> >
>> > Pierre Smits
>> >
>> > *ORRTIZ.COM <http://www.orrtiz.com>*
>> > Services & Solutions for Cloud-
>> > Based Manufacturing, Professional
>> > Services and Retail & Trade
>> > http://www.orrtiz.com
>> >
>> > On Sat, Mar 21, 2015 at 2:42 PM, Mike Kienenberger <mkienenb@gmail.com>
>> > wrote:
>> >
>> > > Have you read https://www.apache.org/foundation/voting.html?
>> > >
>> > > As others have said, the idea is always to build consensus rather than
>> > > force a result.   I guess I've been fortunate in that the projects in
>> > > which I've been most active have always been more interested in
>> > > consensus than individuals forcing a result.   This does add what
>> > > seems to be a bit of bureaucracy at first glance.  For example, we
>> > > "vote" about taking a vote for committers and PMC members (others
>> > > above have called it "DISCUSS").   And if we aren't going to be
>> > > unanimous in our decision to add in a new committer or PMC member,
>> > > then we've always decided to postpone the vote until the individual
>> > > overcomes whatever caused the objection.
>> > >
>> > > I think the reason that code commits can be vetoed is to prevent
>> > > dangerous situations.  Projects can't afford to delay dealing with
>> > > security issues or licensing issues.   I've been on the PMC for two
>> > > different projects for a decade, and to my recollection we've never
>> > > had a code veto.   As far as I know, there's only been a threat of a
>> > > veto one time in those 20 project-years of time, and it was by me.  I
>> > > used the threat of veto with a specific committer who had been asked
>> > > before to not make behavioral changes to the code in the same commit
>> > > where he reformatted every line of the file.   It was making it
>> > > impossible to review his code changes.
>> > >
>> > > Veto is there for emergencies, not for bending others to your
>> technical
>> > > vision.
>> > >
>> > > And yes, we've had some disagreements about how things should be done
>> > > technically, but the final decision usually came down to either "I'm
>> > > willing to do the work" or putting it on hold.
>> > >
>> > >
>> > > On Sat, Mar 21, 2015 at 7:00 AM, Pierre Smits <pierre.smits@gmail.com
>> >
>> > > wrote:
>> > > > If the majority perceives that a nominee is an obstructionist then
>> it
>> > > will
>> > > > be reflected in the voting result. But if the minority - or even
>> only
>> > one
>> > > > voter - perceives that and others don't, then a veto would be a show
>> > > > stopper for innovation, expansion and merit recognition c.q.
>> privilege
>> > > > awarding.
>> > > >
>> > > > I wonder how it can be that democracy is perceived worse than any
>> other
>> > > > cracy when it comes to people in open source projects in general and
>> > ASF
>> > > > projects in particular. Mature projects shouldn't need to have such
>> a
>> > > > mechanism when it comes to people. And it doesn't seem to fit in he
>> > > Apache
>> > > > Way.
>> > > >
>> > > > Best regards
>> > > >
>> > > >
>> > > >
>> > > > Pierre Smits
>> > > >
>> > > > *ORRTIZ.COM <http://www.orrtiz.com>*
>> > > > Services & Solutions for Cloud-
>> > > > Based Manufacturing, Professional
>> > > > Services and Retail & Trade
>> > > > http://www.orrtiz.com
>> > > >
>> > > > On Sat, Mar 21, 2015 at 5:24 AM, Alex Harui <aharui@adobe.com>
>> wrote:
>> > > >
>> > > >> Consensus Approval works great until you have someone who others
>> > rightly
>> > > >> or wrongly perceive as an obstructionist.  Then it just makes
the
>> > whole
>> > > >> project the loser.
>> > > >>
>> > > >> At least one project uses majority approval for new members, but
a
>> > > serious
>> > > >> attempt is made to make sure that the vote is unanimous anyway.
>> Those
>> > > in
>> > > >> opposition deserve to be listened to, but if there are only one
or
>> two
>> > > >> against and lots more in favor, then majority approval avoids
long
>> > > threads
>> > > >> trying to persuade the one or two.  Sure discussing more to achieve
>> > > >> Consensus can be better, but you can also lose momentum of the
>> > committer
>> > > >> candidate and momentum of the rest of the community.
>> > > >>
>> > > >> The -1 vote is an alluring drug.  It can be misused by individuals
>> > who,
>> > > >> consciously or not, cannot avoid the temptation to have control
>> rather
>> > > >> than to collaborate.  But really make sure you listen.  History
is
>> > full
>> > > of
>> > > >> disasters caused by not listening to that one person.
>> > > >>
>> > > >> -Alex
>> > > >>
>> > > >>
>> > >
>> >
>>
>
>


Mime
View raw message