Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

Hi all,

If I understand the various documents/pages available regarding voting
correctly, voting a new member in can't be vetoed. Likewise is it with
respect to voting for board members. If I have missed a page somewhere,
please point me to it and I stand corrected.

The following document https://community.apache.org/newcommitter.html
states:

A positive result is achieved by Consensus Approval i.e. at least 3 +1
votes and no vetoes.

Any veto must be accompanied by reasoning and be prepared to defend it.
Other members can attempt to encourage them to change.

While this document talks about getting new committers in a project, it
also seem to be applicable when it comes to getting new PMC members and
even who chairs the PMC.

So how can it be that when it comes to projects, vetoes can be expressed
and block innovation or growth?
One of the reasons I heard when discussing this was that it establishes
control or manageability of the projects member list.

Wouldn't a simple majority (more +1 than -1 votes) yield the same result?
If someone would feel that non-acceptance of a new person would benefit the
project, wouldn’t it be more proper/righteous  that he should put in the
effort and get a majority of votes?

It is understandable why the ASF (and its projects) have the veto principle
regarding code changes as it ensures that the(released) works of the
project are of a higher quality than the previous work, and that the works
don't change to something else than what is stated in the mission of the
project (meaning that e.g. the primary work of the Apache HTTP project -
httpd can't be converted into e.g. foo widget).
When it comes to people (and organisations), vetoes have proven that it is
a means to force consensus into a certain direction. It might have some
valid grounds when only a few have the biggest gun and they want to keep
others from getting the same gun (and thus rights/power), but in a
environment (as the ASF is) that builds on collaboration it is seems
overkill.

What do you think? Is, when it comes to people, the veto mechanism not out
of place for an ASF project?

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

Re: Veto! Veto?

[Rob Vesse <rv...@dotnetrdf.org>]

On 21/03/2015 19:24, "Pierre Smits" <pi...@gmail.com> wrote:

>If in stead of the veto possibility the simple majority rule was at play,
>it might have been so that fewer project would have reported consecutively
>that no new people were onboarded

A lack of new people on-boarded does not necessarily indicate a project in
trouble (though it may do so).  More often than not in my experience (at
least outside of the Incubator which is a special case) it represents an
established mature project with a low rate of turnover and attrition in
the active community.

If the PMC worries they are stagnating personnel wise they should report
that in their board report or a PMC member could report privately to
board@ if they think there is an issue that the PMC is not publicly
acknowledging.  

On the other hand if the board thinks the projects lack of new
committers/PMC members is an issue then they can and will follow up on
that with the relevant PMC.

Rob

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

It seems resolution 7.G is a result of the rule of no -1 votes leading to
irreconcilable difference. And the rule of no -1 votes seems to be the
result of the rule to grant the power to veto. In stead of making it
simpler it has added layers.

>From the reports of the various projects that I have read regarding new
people coming on board (or lack thereof) the following stands out: several
projects have stated in consecutive reports that there were no new people
on board. This could well be the result of the rule (no -1 votes), due to
the irreconcilable differences. Irreconcilable differences are like vetoes
expressed.

If in stead of the veto possibility the simple majority rule was at play,
it might have been so that fewer project would have reported consecutively
that no new people were onboarded. Not having the power to veto when it
comes to people should, and I expect will lead to more people on board,
more diversity, more innovation and less hampering of progress, less walks
towards the board (as if there have ever been any) and less complexity in
the rulesets.

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 7:59 PM, Pierre Smits <pi...@gmail.com>
wrote:

> It is sometimes the case that the individual, with power in the community,
> can't work with another 'in his eyes difficult' person.
>
> If his contributions are beneficial to the project, if others in the
> project can work with that second person in the collegia/civil manner that
> is expected in a communityl, how can it be acceptable that that first
> person (the one with power who can't work with the other) can block
> acceptance with a veto.
>
> Voting against is not the same as vetoing!
>
> Suppose one of you (with power) finds me 'difficult' within this community
> (as this community is somewhat similar to any other ASF project). And
> suppose I get nominated as PMC member, because of my good contributions and
> of my ability to work with many others.
>
> How would a veto (to have me in) inspire me to do more for the greater
> good, but in stead lead to cycles towards being a loss for this community?
>
> Vetoing people isn't a community builder. It doesn't help when it comes to
> collaborating. It doesn't help when it comes to diversifying the community.
>
> 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:45 PM, Marvin Humphrey <ma...@rectangular.com>
> wrote:
>
>> On Sat, Mar 21, 2015 at 8:29 AM, Benson Margulies <bi...@gmail.com>
>> wrote:
>>
>> > And I emphasize 'range'. There was a talk at Apache Con some years
>> > back about the idea that civility goes in two directions: we all want
>> > to express ourselves in collegial and civil ways, and we also have to
>> > be prepared to accept communications from people with very different
>> > styles, up to and including some that we might individually find
>> > somewhat 'difficult.'
>>
>> It's sometimes the case that an individual has difficulty fitting into one
>> community, yet fits just fine within another.  It's interesting to
>> consider
>> how group dynamics differ.  What positive conditions are present or
>> negative
>> conditions absent in the harmonious group that allow it to function
>> smoothly?
>>
>> In any case, there are no ideal mechanisms for resolving intractable
>> personnel
>> conflicts.  The best we can do is talk through differences in the hope
>> that
>> misunderstandings can be cleared or behavioral modifications adopted.
>>
>> Marvin Humphrey
>>
>
>

Re: Veto! Veto?

[Alex Harui <ah...@adobe.com>]

If person A ‘can’t work’ with person B, in the nomination discussion, if
person A is a reasonable person and sees overwhelming support for person
B, person A should simply vote +0 and try to avoid person B.  It isn’t
like you all work in the same physical office.  Once a group of people
gets large enough, there is always a chance of temporary or long-term
interpersonal conflict between some of the people.  Folks should make
reasonable attempts to show tolerance and get along, but the key for me is
the word “reasonable”.

And this assumes you folks have truly listened to person A.  Is person A
someone who has a better sense of interpersonal dynamics or someone who
has a tendency to hold a grudge?  Why doesn’t person A like person B and
can those who want to vote +1 provide more recent testimony that person B
isn’t going to cause difficulties with every one else that occurred with
person A?  By now person B should have been reasonably active on your
lists.  Any indication of animosity from person B towards person A?

It could just be that person A is the person you’re going to wish never
got voted in.  Or person A is going to turn out to be right and you’ll all
be sorry you used majority approval to let person B in.  How will you
know?  Make sure you and the other voters have thought it through.

-Alex

On 3/21/15, 11:59 AM, "Pierre Smits" <pi...@gmail.com> wrote:

>It is sometimes the case that the individual, with power in the community,
>can't work with another 'in his eyes difficult' person.
>
>If his contributions are beneficial to the project, if others in the
>project can work with that second person in the collegia/civil manner that
>is expected in a communityl, how can it be acceptable that that first
>person (the one with power who can't work with the other) can block
>acceptance with a veto.
>
>Voting against is not the same as vetoing!
>
>Suppose one of you (with power) finds me 'difficult' within this community
>(as this community is somewhat similar to any other ASF project). And
>suppose I get nominated as PMC member, because of my good contributions
>and
>of my ability to work with many others.
>
>How would a veto (to have me in) inspire me to do more for the greater
>good, but in stead lead to cycles towards being a loss for this community?
>
>Vetoing people isn't a community builder. It doesn't help when it comes to
>collaborating. It doesn't help when it comes to diversifying the
>community.
>
>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:45 PM, Marvin Humphrey <ma...@rectangular.com>
>wrote:
>
>> On Sat, Mar 21, 2015 at 8:29 AM, Benson Margulies
>><bi...@gmail.com>
>> wrote:
>>
>> > And I emphasize 'range'. There was a talk at Apache Con some years
>> > back about the idea that civility goes in two directions: we all want
>> > to express ourselves in collegial and civil ways, and we also have to
>> > be prepared to accept communications from people with very different
>> > styles, up to and including some that we might individually find
>> > somewhat 'difficult.'
>>
>> It's sometimes the case that an individual has difficulty fitting into
>>one
>> community, yet fits just fine within another.  It's interesting to
>>consider
>> how group dynamics differ.  What positive conditions are present or
>> negative
>> conditions absent in the harmonious group that allow it to function
>> smoothly?
>>
>> In any case, there are no ideal mechanisms for resolving intractable
>> personnel
>> conflicts.  The best we can do is talk through differences in the hope
>>that
>> misunderstandings can be cleared or behavioral modifications adopted.
>>
>> Marvin Humphrey
>>

Re: Veto! Veto?

[Ted Dunning <te...@gmail.com>]

On Sat, Mar 21, 2015 at 11:59 AM, Pierre Smits <pi...@gmail.com>
wrote:

> It is sometimes the case that the individual, with power in the community,
> can't work with another 'in his eyes difficult' person.
>
> If his contributions are beneficial to the project, if others in the
> project can work with that second person in the collegia/civil manner that
> is expected in a communityl, how can it be acceptable that that first
> person (the one with power who can't work with the other) can block
> acceptance with a veto.
>
> Voting against is not the same as vetoing!
>
> Suppose one of you (with power) finds me 'difficult' within this community
> (as this community is somewhat similar to any other ASF project). And
> suppose I get nominated as PMC member, because of my good contributions and
> of my ability to work with many others.
>
> How would a veto (to have me in) inspire me to do more for the greater
> good, but in stead lead to cycles towards being a loss for this community?
>
> Vetoing people isn't a community builder. It doesn't help when it comes to
> collaborating. It doesn't help when it comes to diversifying the community.
>


Actually, I draw almost exactly opposite conclusions from my experience
with Apache.

A person who is difficult to work with for a minority of the community is a
major impediment to growing the community in my experience, especially with
people who are like the minority.  To be more specific, a prolific
contributor who is an ass to women will prevent the project from ever
getting very many women as contributors, much less as committers.

The potential negative side of having been vetoed for a role in the project
is exactly the reason that personnel decisions are debated in private.  It
is much better to not let the person under consideration know about
potential committership or PMC membership until the answer is positive.  It
isn't uncommon for lack of consensus on a nomination is eventually cured
and the vote passes.  Without privacy on the first vote, the second chance
might well not ever happen.

As a small semantic point, whether voting is the same as vetoing depends
strictly on the voting rules in play.  With consensus as the requirement, a
negative vote is exactly the same as a veto.

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

It is sometimes the case that the individual, with power in the community,
can't work with another 'in his eyes difficult' person.

If his contributions are beneficial to the project, if others in the
project can work with that second person in the collegia/civil manner that
is expected in a communityl, how can it be acceptable that that first
person (the one with power who can't work with the other) can block
acceptance with a veto.

Voting against is not the same as vetoing!

Suppose one of you (with power) finds me 'difficult' within this community
(as this community is somewhat similar to any other ASF project). And
suppose I get nominated as PMC member, because of my good contributions and
of my ability to work with many others.

How would a veto (to have me in) inspire me to do more for the greater
good, but in stead lead to cycles towards being a loss for this community?

Vetoing people isn't a community builder. It doesn't help when it comes to
collaborating. It doesn't help when it comes to diversifying the community.

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:45 PM, Marvin Humphrey <ma...@rectangular.com>
wrote:

> On Sat, Mar 21, 2015 at 8:29 AM, Benson Margulies <bi...@gmail.com>
> wrote:
>
> > And I emphasize 'range'. There was a talk at Apache Con some years
> > back about the idea that civility goes in two directions: we all want
> > to express ourselves in collegial and civil ways, and we also have to
> > be prepared to accept communications from people with very different
> > styles, up to and including some that we might individually find
> > somewhat 'difficult.'
>
> It's sometimes the case that an individual has difficulty fitting into one
> community, yet fits just fine within another.  It's interesting to consider
> how group dynamics differ.  What positive conditions are present or
> negative
> conditions absent in the harmonious group that allow it to function
> smoothly?
>
> In any case, there are no ideal mechanisms for resolving intractable
> personnel
> conflicts.  The best we can do is talk through differences in the hope that
> misunderstandings can be cleared or behavioral modifications adopted.
>
> Marvin Humphrey
>

Re: Veto! Veto?

[Marvin Humphrey <ma...@rectangular.com>]

On Sat, Mar 21, 2015 at 8:29 AM, Benson Margulies <bi...@gmail.com> wrote:

> And I emphasize 'range'. There was a talk at Apache Con some years
> back about the idea that civility goes in two directions: we all want
> to express ourselves in collegial and civil ways, and we also have to
> be prepared to accept communications from people with very different
> styles, up to and including some that we might individually find
> somewhat 'difficult.'

It's sometimes the case that an individual has difficulty fitting into one
community, yet fits just fine within another.  It's interesting to consider
how group dynamics differ.  What positive conditions are present or negative
conditions absent in the harmonious group that allow it to function smoothly?

In any case, there are no ideal mechanisms for resolving intractable personnel
conflicts.  The best we can do is talk through differences in the hope that
misunderstandings can be cleared or behavioral modifications adopted.

Marvin Humphrey

Re: Veto! Veto?

[Benson Margulies <bi...@gmail.com>]

I'd like to suggest backing up from the point where Alex was commenting.

It is an Apache goal to build broad communities, not to build
homogeneous groups. That includes PMC as well as committers. To me,
this suggests that the community-building starts when the person shows
up.

Hypothetical: a new person shows up. That person is contributing. That
person, at least in the eyes of some existing community members, is a
bit difficult. People in the community should be working, actively, to
help that person understand the values of collegiality and community
and to become, as a result, less difficult. So, by the time there's
any possibility of a discussion of PMC membership, that person should
be 'in the range'.

And I emphasize 'range'. There was a talk at Apache Con some years
back about the idea that civility goes in two directions: we all want
to express ourselves in collegial and civil ways, and we also have to
be prepared to accept communications from people with very different
styles, up to and including some that we might individually find
somewhat 'difficult.'

Re: Veto! Veto?

[Alex Harui <ah...@adobe.com>]

Sorry, I wasn’t clear.  It isn’t whether the nominee is perceived as an
obstructionist, it is whether one or two of the voters is perceived as an
obstructions.

There are communities where everyone gets along, and there are communities
where there is a person one can construe as a ‘difficult person’.  See
this article [1], if you haven’t already.

[1] http://producingoss.com/en/difficult-people.html

The fact is, both consensus approval and majority approval are subject to
abuse.  In consensus, a single individual can misuse the power of the
veto.  In majority approval, a faction can rule over a smaller faction.
IMO, you should have a goal to get consensus and put in a good faith
effort to get there, but it sounds like your project may need to switch to
majority approval if someone is being unreasonable.

But again, be careful:  When voting in people, these people have to work
together “forever” so selecting the wrong person, or ignoring the wishes
of too many people may end up causing more problems in the end. There is
no one right answer, but there is probably a “best" answer for your
project and it may not be what other projects do.

-Alex

On 3/21/15, 4:00 AM, "Pierre Smits" <pi...@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 <ah...@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
>>
>>

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On 21 March 2015 at 12:00, Pierre Smits <pi...@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.
>

I really hope (and partly) know that our mature project, use the time and
effort on consensus
(something which of course would not work in a community the size of a
country), for these
projects the VOTE is merely a confirmation of the consensus.

Reading this thread you seem to be working your way around a specific
problem/discussion.
Maybe it would be easier to talk about specifics. As written earlier a PMC
can make their own
rules so we do not need to change the general recommendations.

One of the main reasons I am with ASF, is the consensus model, in many
other foundations
you have either pure anarchy (the loudest win) or strong voting rules,
neither is good for the community.

Consensus building is not easy, being the odd voice in a PMC calls for
healthy nerves and a good deal
of diplomacy. But the tough work is rewarded by the fact that the community
stays united.

just my 2ct.
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 5:24 AM, Alex Harui <ah...@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
> >
> >
>

Re: Veto! Veto?

[Marvin Humphrey <ma...@rectangular.com>]

On Sat, Mar 21, 2015 at 9:34 AM, Dennis E. Hamilton
<de...@acm.org> wrote:
> 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?

See resolution 7.G from the June 2013 Board minutes.

http://apache.org/foundation/records/minutes/2013/board_minutes_2013_06_19.txt

The official policy is that the Board decides, and under extraordinary
circumstances can even completely reconsitute a PMC through the mechanism of a
Board resolution.  For the common case, though, there are specific procedures
for notifying the Board about new PMC members which result in automatic
changes to PMC composition unless a Board member objects.

*   At any time, the PMC Chair can notify the Board of a proposal to invite a
    new PMC member, and need not point to a VOTE result.
*   Any other PMC member can notify the Board about a candidate, but needs to
    point to "a formal decision by the PMC approving of the appointment".

The Board expects personnel decisions to be made by consensus.  A formal
72-hour VOTE with no -1 votes is one way of demonstrating consensus, but a
DISCUSS thread can be enough if it is clear that consensus has been achieved
and a subsequent VOTE would be a formality.

A project might also establish its own procedures regarding how they achieve
consensus on personnel matters.  The more that those procedures diverge from
the norm, the more scrutiny the project can expect from the Board.

Marvin Humphrey

RE: Veto! Veto?

["Dennis E. Hamilton" <de...@acm.org>]

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 <pi...@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 <ja...@apache.org> wrote:
>
>> On 21 March 2015 at 15:24, Pierre Smits <pi...@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 <mk...@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 <ah...@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
>> > > >>
>> > > >>
>> > >
>> >
>>
>
>

Re: Veto! Veto?

[Ted Dunning <te...@gmail.com>]

On Sat, Mar 21, 2015 at 8:50 AM, Pierre Smits <pi...@gmail.com>
wrote:

> 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
successfully.

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.

Re: Veto! Veto?

[Joe Brockmeier <jz...@zonker.net>]

On Sat, Mar 21, 2015, at 11:50 AM, Pierre Smits wrote:
> 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?

Adding a committer or PMC member is an action of trust and shouldn't be
looked at in the same view as code or other technical decisions. It's
*much* harder to reverse adding a person to a project than to grant
committer or PMC status. So while the bar should not be ridiculously
high, it should be approached as a decision that can have serious
consequences down the road.

This is just my experience, but I've been around a number of communities
over the years and I've encountered a few disruptive and difficult
people who (if it'd been an Apache project) I would have -1'ed for
committership or PMC status. They did good work, but were also abrasive
and caused hard feelings for some members of the community. (Usually the
ones the difficult person particularly disliked.) Usually it's a matter
of "death by a thousand cuts" rather than one major issue that you can
point to and say "this person should be removed from the project."

There are a lot of people in open source communities with very thick
skin and/or just happen to be very good at ignoring jerkishness and
focusing on the technical bits. Those are often the folks who call for
voting someone in despite evidence that they are not great at the
"community" bit of "community over code." 

No one *should* have to have a thick skin to participate. So, IMO, it's
entirely justified to allow a minority - or even one person - to veto
committer or (especially) PMC status*. 

Note that the vetoer(s) should articulate valid reasons for this. Nobody
should be vetoing someone because they simply don't like another person.

A person who's contributing *may* at some point feel unhappy if they are
not offered committer or PMC status, but they will almost certainly feel
unhappy if it is taken away because they turn out to be a "poisonous
person" or just don't get "The Apache Way." 

* In those projects that separate committer/PMC.

Best,

jzb
-- 
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Veto! Veto?

[Benson Margulies <bi...@gmail.com>]

In a healthy community, in my experience:

1: someone starts a DISCUSS thread to propose adding a person.

2: if someone else had serious reservations, they state those reservations

3a: remarks from others cause the person with the reservations to
withdraw them, and the group proceeds to a VOTE.
3b: remarks from the person with the reservations cause the
proposer(s) to take some time to work on the issues and bring the
candidate back later.

In other words, the vote is more of a quorum check than a process of
making a decision.

This is the 90% case. It might be the 99% case. The alternative, in
which a vote proceeds in spite of objections, and majority rules, is
far and away the minority case. If there's such strong disagreement
that you are, first of all, in this minority case, and second of all,
even remotely considering the applicability of a veto to the process,
I would be afraid that you've got some serious community issues and
should be worrying about those.

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

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 <pi...@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 <ja...@apache.org> wrote:
>
>> On 21 March 2015 at 15:24, Pierre Smits <pi...@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 <mk...@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 <ah...@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
>> > > >>
>> > > >>
>> > >
>> >
>>
>
>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

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 <ja...@apache.org> wrote:

> On 21 March 2015 at 15:24, Pierre Smits <pi...@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 <mk...@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 <pi...@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 <ah...@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
> > > >>
> > > >>
> > >
> >
>

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On 21 March 2015 at 15:24, Pierre Smits <pi...@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 <mk...@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 <pi...@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 <ah...@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
> > >>
> > >>
> >
>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

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.

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.

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 <mk...@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 <pi...@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 <ah...@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
> >>
> >>
>

Re: Veto! Veto?

[Mike Kienenberger <mk...@gmail.com>]

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 <pi...@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 <ah...@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
>>
>>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

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 <ah...@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
>
>

Re: Veto! Veto?

[Alex Harui <ah...@adobe.com>]

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

On 3/20/15, 6:04 PM, "Pierre Smits" <pi...@gmail.com> wrote:

>Hi all,
>
>If I understand the various documents/pages available regarding voting
>correctly, voting a new member in can't be vetoed. Likewise is it with
>respect to voting for board members. If I have missed a page somewhere,
>please point me to it and I stand corrected.
>
>The following document https://community.apache.org/newcommitter.html
>states:
>
>A positive result is achieved by Consensus Approval i.e. at least 3 +1
>votes and no vetoes.
>
>Any veto must be accompanied by reasoning and be prepared to defend it.
>Other members can attempt to encourage them to change.
>
>While this document talks about getting new committers in a project, it
>also seem to be applicable when it comes to getting new PMC members and
>even who chairs the PMC.
>
>So how can it be that when it comes to projects, vetoes can be expressed
>and block innovation or growth?
>One of the reasons I heard when discussing this was that it establishes
>control or manageability of the projects member list.
>
>Wouldn't a simple majority (more +1 than -1 votes) yield the same result?
>If someone would feel that non-acceptance of a new person would benefit
>the
>project, wouldn’t it be more proper/righteous  that he should put in the
>effort and get a majority of votes?
>
>It is understandable why the ASF (and its projects) have the veto
>principle
>regarding code changes as it ensures that the(released) works of the
>project are of a higher quality than the previous work, and that the works
>don't change to something else than what is stated in the mission of the
>project (meaning that e.g. the primary work of the Apache HTTP project -
>httpd can't be converted into e.g. foo widget).
>When it comes to people (and organisations), vetoes have proven that it is
>a means to force consensus into a certain direction. It might have some
>valid grounds when only a few have the biggest gun and they want to keep
>others from getting the same gun (and thus rights/power), but in a
>environment (as the ASF is) that builds on collaboration it is seems
>overkill.
>
>What do you think? Is, when it comes to people, the veto mechanism not out
>of place for an ASF project?
>
>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

RE: Veto! Veto?

["Dennis E. Hamilton" <de...@acm.org>]

I think we should not confuse consensus with unanimity, because a -1 need not cure to a +1.  The procedures are more nuanced than that, <http://en.wikipedia.org/wiki/Consensus_decision-making>, and there are many ways a cooperating participant can express their concern.  

I do notice that there is confusion about "Consensus Approval" versus "Majority Approval" because the description of "Consensus Approval" uses the "veto" word, <http://www.apache.org/foundation/glossary.html#ConsensusApproval>.  

I have seen nothing that requires unanimity in the absence of the veto rule where it *specifically* applies to commits in ASF principles.  

I notice that "unanimity" is absent as a term in what I read of ASF principles.  I assume that it is intentional that such a clear term is not used.  I read this as allowing for consent that is not full agreement but is an alignment, almost always with any -1 vote cured.  See for example, the description of ways votes are expressed at <http://www.apache.org/foundation/voting.html>.

Another important feature of ASF principles that I see is that ASF is not preoccupied with hypotheticals.  The ASF principles have behind them the presumption that people of good will can work out matters in a non-adversarial manner and that the project communities are trusted to do that.  It is what the ASF expects.  And it works.  We have been told repeatedly in this thread how extremely rare it is for it to be otherwise and the feared hypothetical actually arising.

It is good to stop fretting over hypotheticals and simply operate from good will.  If something unfortunate arises, it can be dealt with in whatever the actual context is.

 - Dennis

-----Original Message-----
From: Pierre Smits [mailto:pierre.smits@gmail.com] 
Sent: Monday, March 23, 2015 01:02
To: dev@community.apache.org
Subject: Re: Veto! Veto?

When it comes to people, consensus (acceptance by unanimity) is the best
thing to have. But if the ASF has as its principle that no vetoes are
allowed, how can it be the remit of a project's PMC have it as its policy?

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 Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Le 22/03/2015 14:42, jan i a écrit :
>
>> On 22 March 2015 at 14:35, Pierre Smits <pi...@gmail.com> wrote:
>>
>>  HI Bertrand,
>>>
>>> Thanks for the clarification regarding
>>> http://community.apache.org/newcommitter.html
>>>
>>> Shouldn't http://www.apache.org/foundation/voting.html then also
>>> explicitly
>>> reflect that vetoes aren't allowed when it comes to on- and ofboarding
>>> contributors as committer and PMC member? That would surely bring
>>> clarity.
>>>
>>>  I would be very unhappy with "aren´t allowed", that is something the
>> individual PMCs should decide !
>>
>
> Yes indeed that's PMCs 's remit; we just need to clarify the ASF default.
>
> Jacques
>
>
>
>> 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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
>>> bdelacretaz@apache.org
>>>
>>>> wrote:
>>>> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
>>>> <ja...@les7arts.com> wrote:
>>>>
>>>>> ...Thanks for the clarification Bertrand, this was also unclear to me.
>>>>>
>>>> Should
>>>>
>>>>> we not amend the newcommitter page?..
>>>>>
>>>> That would be great, I don't have time right now myself.
>>>> -Bertrand
>>>>
>>>>

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On 23 March 2015 at 09:20, Bertrand Delacretaz <bd...@apache.org>
wrote:

> On Mon, Mar 23, 2015 at 9:02 AM, Pierre Smits <pi...@gmail.com>
> wrote:
> >  ...if the ASF has as its principle that no vetoes are
> > allowed, how can it be the remit of a project's PMC have it as its
> policy?...
>
> Our PMCs have a lot of leeway and the board doesn't micromanage them.
>
> In our loosely-coupled communities vetoes can give too much power to
> individuals, that's why https://www.apache.org/foundation/voting.html
> is so restrictive about them.
>
Sadly enough, for procedural votes, that page leaves everything open,
otherwise it is a good page.
"Procedural Votes or Opinion Polls

*TBS"*


Rgds
jan I.


> I'd say broadly allowing vetoes works as long as people don't use
> them, or just use them in a friendly and temporary way. But if people
> are all friendly you don't really need rules anyway ;-)
>
> -Bertrand
>

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Mar 23, 2015 at 9:02 AM, Pierre Smits <pi...@gmail.com> wrote:
>  ...if the ASF has as its principle that no vetoes are
> allowed, how can it be the remit of a project's PMC have it as its policy?...

Our PMCs have a lot of leeway and the board doesn't micromanage them.

In our loosely-coupled communities vetoes can give too much power to
individuals, that's why https://www.apache.org/foundation/voting.html
is so restrictive about them.

I'd say broadly allowing vetoes works as long as people don't use
them, or just use them in a friendly and temporary way. But if people
are all friendly you don't really need rules anyway ;-)

-Bertrand

Re: Veto! Veto?

[Rich Bowen <rb...@rcbowen.com>]

On 03/23/2015 01:31 PM, Ted Dunning wrote:
>> Here's a better not-quite-so-hypothetical example.   A project like MyFaces
>> >has to pass the TCK testing suite provided by Oracle.   We would not want
>> >to allow unrestricted commit access by someone who did not
>> >understand profoundly and intuitively that the JSF API portion of the
>> >project has a predefined public API which cannot be changed.
>
> Some projects feel this way.  Others have found that review is just as
> effective as restricting commit bits tightly.  The classic case is
> Subversion which has a very high profile (and thus is obliged to have
> stable API's).  That PMC offers a commit bit to anyone who asks.
>
> People seem to forget that erroneous commits that pass review can simply be
> reverted.  That is one of the points of using version control.
>


Well, sure, and as the board, or as comdev, we can say that that's best 
practice, and encourage projects to adopt that. But we're not going to 
*require* that they do that. Because they might have a different way 
that they want to do things, and it's not our job to tell them that 
their reasons are invalid.

The ASF exists to facilitate project communities. Not to dictate to them 
how they should run their project. Just to make a welcoming place for 
them to operate. As such, we keep the MUST rules to a minimum, and the 
SHOULD suggestions are where most of our discussion happens.


-- 
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On 24 March 2015 at 16:15, Rich Bowen <rb...@rcbowen.com> wrote:

>
>
> On 03/24/2015 11:01 AM, jan i wrote:
>
>> Consider the scenario a PMC discusses, and the vote is called (indirectly
>> to stop critical voices) early, then a -1 is the only
>> way to express your opinion.
>>
>> When we define rules, as important as this, we should not look so much at
>> the "good weather" situations, but where things dont follow the book,
>> like a vote called on purpose too early.
>>
>
> In that case, veto the *vote*, not the person.
>
you are completely right, this is my real concern.

rgds
jan i.

>
> That is, if you feel that a community has called a vote early specifically
> to quell dissent, then you, as a community member, should declare the vote
> invalid.
>
> "This vote is premature, and I declare it invalid. Let's discuss this some
> more until there's consensus."
>
> The real problem here is creating situations where a veto can happen at
> all. As Greg has said a bunch of times, in this thread and in others, votes
> are not the place to generate consensus. To quote:
>
> "Stop with the "Votes" ... Damn I hate that. Generate consensus. A vote
> does not generate consensus. It forces a result, and those voting fall into
> winners/losers rather than general consensus."
>
>
>
>
> --
> Rich Bowen - rbowen@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>

Re: Veto! Veto?

[Rich Bowen <rb...@rcbowen.com>]

On 03/24/2015 11:01 AM, jan i wrote:
> Consider the scenario a PMC discusses, and the vote is called (indirectly
> to stop critical voices) early, then a -1 is the only
> way to express your opinion.
>
> When we define rules, as important as this, we should not look so much at
> the "good weather" situations, but where things dont follow the book,
> like a vote called on purpose too early.

In that case, veto the *vote*, not the person.

That is, if you feel that a community has called a vote early 
specifically to quell dissent, then you, as a community member, should 
declare the vote invalid.

"This vote is premature, and I declare it invalid. Let's discuss this 
some more until there's consensus."

The real problem here is creating situations where a veto can happen at 
all. As Greg has said a bunch of times, in this thread and in others, 
votes are not the place to generate consensus. To quote:

"Stop with the "Votes" ... Damn I hate that. Generate consensus. A vote 
does not generate consensus. It forces a result, and those voting fall 
into winners/losers rather than general consensus."



-- 
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Mar 24, 2015 at 11:27 AM, jan i <ja...@apache.org> wrote:
> ...https://www.apache.org/foundation/voting.html leaves it totally open:
> Procedural Votes or Opinion Polls
> *TBS* ...

The beginning of that page gives good info on procedural votes, so I
have removed this section for now.

If someone wants to flesh it out instead that's possible, but IMO the
"Votes on procedural issues ..." paragraph at the beginning of that
page is good enough.

-Bertrand

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On 24 March 2015 at 10:43, Bertrand Delacretaz <bd...@apache.org>
wrote:

> On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
> <ja...@les7arts.com> wrote:
> > Who will update the https://community.apache.org/newcommitter.html
> page?*
>
> I've done that, it now says "In general, committer elections are
> majority approval votes, as described on the Apache Voting Process
> page" with a link.
>
+1, a good wording that gives a recommendation without disallowing other
processes.

Since this is really a procedural vote on
https://www.apache.org/foundation/voting.html which leaves it totally open:
Procedural Votes or Opinion Polls

*TBS*


 It might be a good idea to update that page as well.


rgds

jan I.



> -Bertrand
>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

No worries. Just helping to get to the clearest ASF message. :-)

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 Tue, Mar 24, 2015 at 11:57 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:

> On Tue, Mar 24, 2015 at 11:43 AM, Pierre Smits <pi...@gmail.com>
> wrote:
> >... Shouldn't the sentence 'Any veto...
> > then be removed from http://community.apache.org/newcommitter.html?...
>
> Of course, tunnel vision at work here ;-)
>
> I have removed it now, thanks for noticing!
> -Bertrand
>

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Mar 24, 2015 at 11:43 AM, Pierre Smits <pi...@gmail.com> wrote:
>... Shouldn't the sentence 'Any veto...
> then be removed from http://community.apache.org/newcommitter.html?...

Of course, tunnel vision at work here ;-)

I have removed it now, thanks for noticing!
-Bertrand

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Mar 24, 2015 at 3:47 PM, Rich Bowen <rb...@rcbowen.com> wrote:
> On 03/24/2015 06:43 AM, Pierre Smits wrote:
>> Shouldn't the sentence 'Any veto must be accompanied by reasoning and be
>> prepared to defend it. Other members can attempt to encourage them to
>> change.' then be removed
>> fromhttp://community.apache.org/newcommitter.html?
>
> That sentence, and that sentiment, is incredibly important....

Totally agreed when vetoes are applicable, but Pierre's comment was
made just after I removed the notion of veto just above that phrase.
So it didn't make sense there anymore.

-Bertrand

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On 24 March 2015 at 15:53, Benson Margulies <bi...@gmail.com> wrote:

> On Tue, Mar 24, 2015 at 10:47 AM, Rich Bowen <rb...@rcbowen.com> wrote:
> >
> >
> > On 03/24/2015 06:43 AM, Pierre Smits wrote:
> >>
> >> Shouldn't the sentence 'Any veto must be accompanied by reasoning and be
> >> prepared to defend it. Other members can attempt to encourage them to
> >> change.' then be removed
> >> fromhttp://community.apache.org/newcommitter.html?
> >
> >
> > That sentence, and that sentiment, is incredibly important. Thinking
> that a
> > veto is final, written in stone, and never to be revisited, is kind of
> > damaging to conversation.
>
> The 'commit veto' process is, I think, a different matter altogether
> from a discussion about a new person or about a new website. The idea
> of the code veto is 'This code is so wrong that it has to leave the
> repo _right now_.' One casts such a veto immediately upon observing
> the commit, and then the required reasoning starts the community
> process as to whether it stays out of the repo.
>
> If decisions about people are consensus decisions, subject to
> blocking, then the 'veto' comes at the _end_, _after_ the discussion
> in which people air their objections. So, I claim, this sentence isn't
> entirely apropos to the subject of this thread.
>

Consider the scenario a PMC discusses, and the vote is called (indirectly
to stop critical voices) early, then a -1 is the only
way to express your opinion.

When we define rules, as important as this, we should not look so much at
the "good weather" situations, but where things dont follow the book,
like a vote called on purpose too early.

rgds
jan i.


>
>
> >
> > --
> > Rich Bowen - rbowen@rcbowen.com - @rbowen
> > http://apachecon.com/ - @apachecon
>

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Mar 24, 2015 at 4:00 PM, Pierre Smits <pi...@gmail.com> wrote:
> ...Consensus in a procedural issue (through voting) is unanimity. Everybody
> agrees....

That's not how I understand our consensus, as in the footnote of [1]
my vision of consensus at the ASF is "widespread agreement among
people who have decision power".

Unanimity is ideal of course, but in our loosely-coupled and
opinionated communities requiring unanimity can block progress.

-Bertrand

[1] https://community.apache.org/apache-way/apache-project-maturity-model.html

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

Consensus in a procedural issue (through voting) is unanimity. Everybody
agrees.

In procedural issues the veto principle doesn't work as it stalls
discussion, hardens viewpoints. Leading to people moving away from getting
to a compromise.

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 Tue, Mar 24, 2015 at 3:53 PM, Benson Margulies <bi...@gmail.com>
wrote:

> On Tue, Mar 24, 2015 at 10:47 AM, Rich Bowen <rb...@rcbowen.com> wrote:
> >
> >
> > On 03/24/2015 06:43 AM, Pierre Smits wrote:
> >>
> >> Shouldn't the sentence 'Any veto must be accompanied by reasoning and be
> >> prepared to defend it. Other members can attempt to encourage them to
> >> change.' then be removed
> >> fromhttp://community.apache.org/newcommitter.html?
> >
> >
> > That sentence, and that sentiment, is incredibly important. Thinking
> that a
> > veto is final, written in stone, and never to be revisited, is kind of
> > damaging to conversation.
>
> The 'commit veto' process is, I think, a different matter altogether
> from a discussion about a new person or about a new website. The idea
> of the code veto is 'This code is so wrong that it has to leave the
> repo _right now_.' One casts such a veto immediately upon observing
> the commit, and then the required reasoning starts the community
> process as to whether it stays out of the repo.
>
> If decisions about people are consensus decisions, subject to
> blocking, then the 'veto' comes at the _end_, _after_ the discussion
> in which people air their objections. So, I claim, this sentence isn't
> entirely apropos to the subject of this thread.
>
>
> >
> > --
> > Rich Bowen - rbowen@rcbowen.com - @rbowen
> > http://apachecon.com/ - @apachecon
>

Re: Veto! Veto?

[Benson Margulies <bi...@gmail.com>]

On Tue, Mar 24, 2015 at 10:47 AM, Rich Bowen <rb...@rcbowen.com> wrote:
>
>
> On 03/24/2015 06:43 AM, Pierre Smits wrote:
>>
>> Shouldn't the sentence 'Any veto must be accompanied by reasoning and be
>> prepared to defend it. Other members can attempt to encourage them to
>> change.' then be removed
>> fromhttp://community.apache.org/newcommitter.html?
>
>
> That sentence, and that sentiment, is incredibly important. Thinking that a
> veto is final, written in stone, and never to be revisited, is kind of
> damaging to conversation.

The 'commit veto' process is, I think, a different matter altogether
from a discussion about a new person or about a new website. The idea
of the code veto is 'This code is so wrong that it has to leave the
repo _right now_.' One casts such a veto immediately upon observing
the commit, and then the required reasoning starts the community
process as to whether it stays out of the repo.

If decisions about people are consensus decisions, subject to
blocking, then the 'veto' comes at the _end_, _after_ the discussion
in which people air their objections. So, I claim, this sentence isn't
entirely apropos to the subject of this thread.


>
> --
> Rich Bowen - rbowen@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon

Re: Veto! Veto?

[Rich Bowen <rb...@rcbowen.com>]

On 03/24/2015 06:43 AM, Pierre Smits wrote:
> Shouldn't the sentence 'Any veto must be accompanied by reasoning and be
> prepared to defend it. Other members can attempt to encourage them to
> change.' then be removed fromhttp://community.apache.org/newcommitter.html?

That sentence, and that sentiment, is incredibly important. Thinking 
that a veto is final, written in stone, and never to be revisited, is 
kind of damaging to conversation.

-- 
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

Shouldn't the sentence 'Any veto must be accompanied by reasoning and be
prepared to defend it. Other members can attempt to encourage them to
change.' then be removed from http://community.apache.org/newcommitter.html?

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 Tue, Mar 24, 2015 at 10:43 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:

> On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
> <ja...@les7arts.com> wrote:
> > Who will update the https://community.apache.org/newcommitter.html
> page?*
>
> I've done that, it now says "In general, committer elections are
> majority approval votes, as described on the Apache Voting Process
> page" with a link.
>
> -Bertrand
>

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Mar 24, 2015 at 2:33 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> ...The ambiguity of voting.html has long irritated me and it was on my
> own internal list of policies to clarify.  I figured I would tackle it
> later because it is so fundamental, but perhaps it will force itself
> onto the agenda sooner....

That document has the advantage of being concise, we shouldn't lose that.

I personally don't like the way
https://community.apache.org/newcommitter.html and similar pages
duplicate information instead of referring to it - fixing that is a
big task, but I agree that it's long overdue.

-Bertrand

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On Tuesday, March 24, 2015, Greg Stein <gs...@gmail.com> wrote:

> On Tue, Mar 24, 2015 at 8:33 AM, Marvin Humphrey <marvin@rectangular.com
> <javascript:;>>
> wrote:
>
> > On Tue, Mar 24, 2015 at 2:43 AM, Bertrand Delacretaz
> > <bdelacretaz@apache.org <javascript:;>> wrote:
> > > On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
> > > <jacques.le.roux@les7arts.com <javascript:;>> wrote:
> > >> Who will update the https://community.apache.org/newcommitter.html
> > page?*
> > >
> > > I've done that, it now says "In general, committer elections are
> > > majority approval votes, as described on the Apache Voting Process
> > > page" with a link.
> >
> > That's not my understanding. It's not what I've heard from the Board
> > over the years, particularly from Greg. And I believe that it's for a
> > very good reason that personnel votes at Apache are not majority rule:
> > majority rule forces a result rather than creates consensus.
> >
>
> I dislike all voting, yes. Consensus through discussion is definitely a
> better approach.
>
> Concretely: I don't think there is any specific recommendation for how a
> PMC/community decides upon new committers. I've seen many mechanisms. In
> fact, within Apache Subversion, a committer can be added by any *singular*
> PMC member, no vote required (but their resulting commit rights are
> limited).

Just for my understanding,  does subversion have 2 types of committer one
with the full subversion repo bit, and another limited (to part of the
repo) ?

rgds
jan i

>
> For PMC Members, Roy has stated [on general@incubator, on 1/31/2012] that:
>
> "Well, it boils down to the fact that making someone a PMC member gives
> them veto power over the changes you make.  The only way that works
> socially is if everyone currently on the PMC agrees that person is a peer."
>
> >...
>
> Cheers,
> -g
>


-- 
Sent from My iPad, sorry for any misspellings.

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Mar 24, 2015 at 2:47 PM, Greg Stein <gs...@gmail.com> wrote:

> ...I dislike all voting, yes. Consensus through discussion is definitely a
> better approach....

That's why I wrote " *in general*, committer elections are..." at
https://community.apache.org/newcommitter.html - I think that page
needs more reworking than that, so consider that just a quick fix that
goes in the right direction.

-Bertrand

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

D**n. Type-ahead....

If it weren't all that difficult and important to do the righteous thing,
we wouldn't have all the 'voting' aspects defined in our by-laws, and we
could run the ASF as one of its projects.

Pierre Smits

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

On Tue, Mar 24, 2015 at 4:28 PM, Pierre Smits <pi...@gmail.com>
wrote:

> If it weren't all that difficult and imported to do the righteous thing,
> we wouldn't have all the 'voting' aspects defined in our by-laws, and we
> could run the ASF as one of its projects.
>
> 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 Tue, Mar 24, 2015 at 4:21 PM, Pierre Smits <pi...@gmail.com>
> wrote:
>
>>
>>
>> You can't coerce consensus regarding procedural issues by saying:   'do
>> it my way or I veto!'
>> Soon everybody will: veto. Veto. Veto! VETO. VETO!!
>>
>> Even vetoing a vote is not generating consensus.
>>
>>
>> --
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

If it weren't all that difficult and imported to do the righteous thing, we
wouldn't have all the 'voting' aspects defined in our by-laws, and we could
run the ASF as one of its projects.

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 Tue, Mar 24, 2015 at 4:21 PM, Pierre Smits <pi...@gmail.com>
wrote:

>
>
> You can't coerce consensus regarding procedural issues by saying:   'do it
> my way or I veto!'
> Soon everybody will: veto. Veto. Veto! VETO. VETO!!
>
> Even vetoing a vote is not generating consensus.
>
>
> --
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>

Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

You can't coerce consensus regarding procedural issues by saying:   'do it
my way or I veto!'
Soon everybody will: veto. Veto. Veto! VETO. VETO!!

Even vetoing a vote is not generating consensus.


-- 
Pierre Smits

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

Re: Veto! Veto?

[Jim Jagielski <ji...@jaguNET.com>]

IMO, voting is simply formalizing an already achieved consensus.
Voting can also be done to gauge a consensus, but only if done
informally, IMO (e.g. "I think we should do Foo. What do you all
thing?" and then wait for some +1s, -0s, etc...).

You drive consensus by discussion and collaboration and
compromise; not by voting.

Re: Veto! Veto?

[Eric Covener <co...@gmail.com>]

On Tue, Mar 24, 2015 at 9:47 AM, Greg Stein <gs...@gmail.com> wrote:
> In fact, within Apache Subversion, a committer can be added by any *singular*
> PMC member, no vote required (but their resulting commit rights are
> limited).

How does that interact/co-exist with UCB?




-- 
Eric Covener
covener@gmail.com

RE: Veto! Veto?

["Dennis E. Hamilton" <de...@acm.org>]

I think it is great that there are all of these views on the importance of consensus and how that ties to the nurturing of community and harmony toward a common purpose.  I wouldn't even hang around ASF, after having grasped what little of that as I have, if it was not the case.

And it is obvious, from this discussion, that there needs to be room for a PMC to establish where they stand on certain kinds of deliberation and resolution.  And that is something the PMC determines by whatever the starting process is.

A concern I have is related to podlings, ones that do not have many experienced committers, where customization happens without explanation by mentors and newbies will be launched into the world with different ideas about how things are.

For me, I am thinking that simple principles, in particular what -1 means when it is not the specific case of a release or commit, need to have simple practices that everyone can use as a starting point before having to understand the nuances. (And I am not in favor of -1 from anyone counting as a hard-stop veto, which is what I have been seeing in at least one place.)

The requirement for mentor concurrence on personnel matters is also an opportunity for coaching if things seem to be going pear-shaped. (I don't know that is a principle for podlings, it is how it worked when AOO was in the incubator.  We also did not have any mentors go native.)

Another thing has to do with confusion of committer invitation and [P]PMC invitation.  I understand that a combined invitation is trumped by the [P]PMC policies and there are *specific* procedures in place for how concurrence of higher powers is obtained before an invitation should be presented to the invitee.  And, while different PMCs have different ways of doing all of this, I think it is important to understand that they are different things and local principles will determine how they are amalgamated, discussed, and resolved and whether invariably tied together.

I'm not seeking some sort of absolutism.  I do think there needs to be a reasonable stable ground for the principles, ones that can be easily followed, and that lean toward the fostering of community.  I don't think it is a good idea to be all over the map when a PPMC fires up with initial committers that are not ASF vaccinated and whose further arrivals need not be either.

 - Dennis

-----Original Message-----
From: Greg Stein [mailto:gstein@gmail.com] 
Sent: Tuesday, March 24, 2015 06:47
To: Marvin Humphrey
Cc: dev@community.apache.org
Subject: Re: Veto! Veto?

[ ... ]

I dislike all voting, yes. Consensus through discussion is definitely a
better approach.

Concretely: I don't think there is any specific recommendation for how a
PMC/community decides upon new committers. I've seen many mechanisms. In
fact, within Apache Subversion, a committer can be added by any *singular*
PMC member, no vote required (but their resulting commit rights are
limited).

For PMC Members, Roy has stated [on general@incubator, on 1/31/2012] that:

"Well, it boils down to the fact that making someone a PMC member gives
them veto power over the changes you make.  The only way that works
socially is if everyone currently on the PMC agrees that person is a peer."

>...

Cheers,
-g

RE: Veto! Veto?

["Dennis E. Hamilton" <de...@acm.org>]

In more-formal arrangements, do-overs must be initiated by someone whose vote was on the prevailing side of the previous deliberation.  This is a way to avoid constant reconsideration in what is more like an adversarial procedure.  The local government where I live is in a state of perpetual reconsideration via voter initiatives.    

I think the idea for Apache is that if this situation arises, there is a breakdown in the community.  We have some awful examples in my country of what happens when that becomes toxic and legislatures would rather fight than govern.

After consensus, of course, reconsideration is always possible based on new information or some other change in the state of affairs, unless there is some serious gaming going on.  

 - Dennis

-----Original Message-----
From: Pierre Smits [mailto:pierre.smits@gmail.com] 
Sent: Tuesday, March 24, 2015 07:00
To: dev@community.apache.org
Subject: Re: Veto! Veto?

I agree: consensus reached through discussion as far better than having to
do the (majority rule) vote. As with that, you -for sure - don't always get
what you want.

But it is - by far-the best alternative available to keep movement in a
project. And do-overs are possible.

Pierre

Op dinsdag 24 maart 2015 heeft Greg Stein <gs...@gmail.com> het volgende
geschreven:

> On Tue, Mar 24, 2015 at 8:33 AM, Marvin Humphrey <marvin@rectangular.com
> <javascript:;>>
> wrote:
>
> > On Tue, Mar 24, 2015 at 2:43 AM, Bertrand Delacretaz
> > <bdelacretaz@apache.org <javascript:;>> wrote:
> > > On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
> > > <jacques.le.roux@les7arts.com <javascript:;>> wrote:
> > >> Who will update the https://community.apache.org/newcommitter.html
> > page?*
> > >
> > > I've done that, it now says "In general, committer elections are
> > > majority approval votes, as described on the Apache Voting Process
> > > page" with a link.
> >
> > That's not my understanding. It's not what I've heard from the Board
> > over the years, particularly from Greg. And I believe that it's for a
> > very good reason that personnel votes at Apache are not majority rule:
> > majority rule forces a result rather than creates consensus.
> >
>
> I dislike all voting, yes. Consensus through discussion is definitely a
> better approach.
>
> Concretely: I don't think there is any specific recommendation for how a
> PMC/community decides upon new committers. I've seen many mechanisms. In
> fact, within Apache Subversion, a committer can be added by any *singular*
> PMC member, no vote required (but their resulting commit rights are
> limited).
>
> For PMC Members, Roy has stated [on general@incubator, on 1/31/2012] that:
>
> "Well, it boils down to the fact that making someone a PMC member gives
> them veto power over the changes you make.  The only way that works
> socially is if everyone currently on the PMC agrees that person is a peer."
>
> >...
>
> Cheers,
> -g
>


-- 
Pierre Smits

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

Re: Veto! Veto?

[Mike Kienenberger <mk...@gmail.com>]

I believe Ross Gardler, our current president said it extremely well:

        The Apache Way works because of our core principles of
        consensus building within a meritocratic structure. We are not
        a democracy, nor are we an oligarchy.

As Jim said, and this is true in the projects I am active, the point
of the vote is to either gauge consensus or to formalize consensus.
We +1/+0/-1 out of tradition.  But we would arrive at the exact same
conclusion if we skipped all that and just left it as a DISCUSS
thread.


On Tue, Mar 24, 2015 at 10:39 AM, Benson Margulies
<bi...@gmail.com> wrote:
> Perhaps this discussion stems from questions about how Apache uses the
> term 'consensus'.
>
> In the rest of the world, there is a formally defined 'consensus
> decision process'. The goal of this process is to make decisions when
> possible, and leave the status quo otherwise. Very roughly, discussion
> takes place. When the moderator perceives a possible consensus, the
> moderator asks, 'does anyone block consensus'? At that point, people
> think very carefully, balancing the value of action against the
> importance of an objection. If people have a too-low threshold for
> blocking consensus, then nothing ever happens. If people have a
> too-high threshold, then disagreements build and other disfunction
> sets in.
>
> You can model an Apache 'vote with veto' as an electronic consensus
> test. -1 means 'I'm not thrilled, but I'm open to persuasion.' VETO is
> a blocking of consensus. +0 is 'I'm not thrilled, but I'm I won't
> block it.'
>
> The concept of 'procedural votes' is that there are some topics that
> don't deserve all of this angst; that a defined quorum of people in
> favor is enough. Whether PMC or commit should be consensus or
> procedural I leave to others to debate; I just offer this to try to
> put the veto into context.
>
>
>
>
> On Tue, Mar 24, 2015 at 10:00 AM, Pierre Smits <pi...@gmail.com> wrote:
>> I agree: consensus reached through discussion as far better than having to
>> do the (majority rule) vote. As with that, you -for sure - don't always get
>> what you want.
>>
>> But it is - by far-the best alternative available to keep movement in a
>> project. And do-overs are possible.
>>
>> Pierre
>>
>> Op dinsdag 24 maart 2015 heeft Greg Stein <gs...@gmail.com> het volgende
>> geschreven:
>>
>>> On Tue, Mar 24, 2015 at 8:33 AM, Marvin Humphrey <marvin@rectangular.com
>>> <javascript:;>>
>>> wrote:
>>>
>>> > On Tue, Mar 24, 2015 at 2:43 AM, Bertrand Delacretaz
>>> > <bdelacretaz@apache.org <javascript:;>> wrote:
>>> > > On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
>>> > > <jacques.le.roux@les7arts.com <javascript:;>> wrote:
>>> > >> Who will update the https://community.apache.org/newcommitter.html
>>> > page?*
>>> > >
>>> > > I've done that, it now says "In general, committer elections are
>>> > > majority approval votes, as described on the Apache Voting Process
>>> > > page" with a link.
>>> >
>>> > That's not my understanding. It's not what I've heard from the Board
>>> > over the years, particularly from Greg. And I believe that it's for a
>>> > very good reason that personnel votes at Apache are not majority rule:
>>> > majority rule forces a result rather than creates consensus.
>>> >
>>>
>>> I dislike all voting, yes. Consensus through discussion is definitely a
>>> better approach.
>>>
>>> Concretely: I don't think there is any specific recommendation for how a
>>> PMC/community decides upon new committers. I've seen many mechanisms. In
>>> fact, within Apache Subversion, a committer can be added by any *singular*
>>> PMC member, no vote required (but their resulting commit rights are
>>> limited).
>>>
>>> For PMC Members, Roy has stated [on general@incubator, on 1/31/2012] that:
>>>
>>> "Well, it boils down to the fact that making someone a PMC member gives
>>> them veto power over the changes you make.  The only way that works
>>> socially is if everyone currently on the PMC agrees that person is a peer."
>>>
>>> >...
>>>
>>> Cheers,
>>> -g
>>>
>>
>>
>> --
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com

Re: Veto! Veto?

[Benson Margulies <bi...@gmail.com>]

Perhaps this discussion stems from questions about how Apache uses the
term 'consensus'.

In the rest of the world, there is a formally defined 'consensus
decision process'. The goal of this process is to make decisions when
possible, and leave the status quo otherwise. Very roughly, discussion
takes place. When the moderator perceives a possible consensus, the
moderator asks, 'does anyone block consensus'? At that point, people
think very carefully, balancing the value of action against the
importance of an objection. If people have a too-low threshold for
blocking consensus, then nothing ever happens. If people have a
too-high threshold, then disagreements build and other disfunction
sets in.

You can model an Apache 'vote with veto' as an electronic consensus
test. -1 means 'I'm not thrilled, but I'm open to persuasion.' VETO is
a blocking of consensus. +0 is 'I'm not thrilled, but I'm I won't
block it.'

The concept of 'procedural votes' is that there are some topics that
don't deserve all of this angst; that a defined quorum of people in
favor is enough. Whether PMC or commit should be consensus or
procedural I leave to others to debate; I just offer this to try to
put the veto into context.




On Tue, Mar 24, 2015 at 10:00 AM, Pierre Smits <pi...@gmail.com> wrote:
> I agree: consensus reached through discussion as far better than having to
> do the (majority rule) vote. As with that, you -for sure - don't always get
> what you want.
>
> But it is - by far-the best alternative available to keep movement in a
> project. And do-overs are possible.
>
> Pierre
>
> Op dinsdag 24 maart 2015 heeft Greg Stein <gs...@gmail.com> het volgende
> geschreven:
>
>> On Tue, Mar 24, 2015 at 8:33 AM, Marvin Humphrey <marvin@rectangular.com
>> <javascript:;>>
>> wrote:
>>
>> > On Tue, Mar 24, 2015 at 2:43 AM, Bertrand Delacretaz
>> > <bdelacretaz@apache.org <javascript:;>> wrote:
>> > > On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
>> > > <jacques.le.roux@les7arts.com <javascript:;>> wrote:
>> > >> Who will update the https://community.apache.org/newcommitter.html
>> > page?*
>> > >
>> > > I've done that, it now says "In general, committer elections are
>> > > majority approval votes, as described on the Apache Voting Process
>> > > page" with a link.
>> >
>> > That's not my understanding. It's not what I've heard from the Board
>> > over the years, particularly from Greg. And I believe that it's for a
>> > very good reason that personnel votes at Apache are not majority rule:
>> > majority rule forces a result rather than creates consensus.
>> >
>>
>> I dislike all voting, yes. Consensus through discussion is definitely a
>> better approach.
>>
>> Concretely: I don't think there is any specific recommendation for how a
>> PMC/community decides upon new committers. I've seen many mechanisms. In
>> fact, within Apache Subversion, a committer can be added by any *singular*
>> PMC member, no vote required (but their resulting commit rights are
>> limited).
>>
>> For PMC Members, Roy has stated [on general@incubator, on 1/31/2012] that:
>>
>> "Well, it boils down to the fact that making someone a PMC member gives
>> them veto power over the changes you make.  The only way that works
>> socially is if everyone currently on the PMC agrees that person is a peer."
>>
>> >...
>>
>> Cheers,
>> -g
>>
>
>
> --
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

I agree: consensus reached through discussion as far better than having to
do the (majority rule) vote. As with that, you -for sure - don't always get
what you want.

But it is - by far-the best alternative available to keep movement in a
project. And do-overs are possible.

Pierre

Op dinsdag 24 maart 2015 heeft Greg Stein <gs...@gmail.com> het volgende
geschreven:

> On Tue, Mar 24, 2015 at 8:33 AM, Marvin Humphrey <marvin@rectangular.com
> <javascript:;>>
> wrote:
>
> > On Tue, Mar 24, 2015 at 2:43 AM, Bertrand Delacretaz
> > <bdelacretaz@apache.org <javascript:;>> wrote:
> > > On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
> > > <jacques.le.roux@les7arts.com <javascript:;>> wrote:
> > >> Who will update the https://community.apache.org/newcommitter.html
> > page?*
> > >
> > > I've done that, it now says "In general, committer elections are
> > > majority approval votes, as described on the Apache Voting Process
> > > page" with a link.
> >
> > That's not my understanding. It's not what I've heard from the Board
> > over the years, particularly from Greg. And I believe that it's for a
> > very good reason that personnel votes at Apache are not majority rule:
> > majority rule forces a result rather than creates consensus.
> >
>
> I dislike all voting, yes. Consensus through discussion is definitely a
> better approach.
>
> Concretely: I don't think there is any specific recommendation for how a
> PMC/community decides upon new committers. I've seen many mechanisms. In
> fact, within Apache Subversion, a committer can be added by any *singular*
> PMC member, no vote required (but their resulting commit rights are
> limited).
>
> For PMC Members, Roy has stated [on general@incubator, on 1/31/2012] that:
>
> "Well, it boils down to the fact that making someone a PMC member gives
> them veto power over the changes you make.  The only way that works
> socially is if everyone currently on the PMC agrees that person is a peer."
>
> >...
>
> Cheers,
> -g
>


-- 
Pierre Smits

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

Re: Veto! Veto?

[Greg Stein <gs...@gmail.com>]

On Tue, Mar 24, 2015 at 8:33 AM, Marvin Humphrey <ma...@rectangular.com>
wrote:

> On Tue, Mar 24, 2015 at 2:43 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
> > <ja...@les7arts.com> wrote:
> >> Who will update the https://community.apache.org/newcommitter.html
> page?*
> >
> > I've done that, it now says "In general, committer elections are
> > majority approval votes, as described on the Apache Voting Process
> > page" with a link.
>
> That's not my understanding. It's not what I've heard from the Board
> over the years, particularly from Greg. And I believe that it's for a
> very good reason that personnel votes at Apache are not majority rule:
> majority rule forces a result rather than creates consensus.
>

I dislike all voting, yes. Consensus through discussion is definitely a
better approach.

Concretely: I don't think there is any specific recommendation for how a
PMC/community decides upon new committers. I've seen many mechanisms. In
fact, within Apache Subversion, a committer can be added by any *singular*
PMC member, no vote required (but their resulting commit rights are
limited).

For PMC Members, Roy has stated [on general@incubator, on 1/31/2012] that:

"Well, it boils down to the fact that making someone a PMC member gives
them veto power over the changes you make.  The only way that works
socially is if everyone currently on the PMC agrees that person is a peer."

>...

Cheers,
-g

Re: Veto! Veto?

[Marvin Humphrey <ma...@rectangular.com>]

On Tue, Mar 24, 2015 at 2:43 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
> <ja...@les7arts.com> wrote:
>> Who will update the https://community.apache.org/newcommitter.html page?*
>
> I've done that, it now says "In general, committer elections are
> majority approval votes, as described on the Apache Voting Process
> page" with a link.

That's not my understanding. It's not what I've heard from the Board
over the years, particularly from Greg. And I believe that it's for a
very good reason that personnel votes at Apache are not majority rule:
majority rule forces a result rather than creates consensus.

The ambiguity of voting.html has long irritated me and it was on my
own internal list of policies to clarify.  I figured I would tackle it
later because it is so fundamental, but perhaps it will force itself
onto the agenda sooner.

I contend that the reasoning applied in this thread that personnel
votes are "procedural votes" is not correct, and that therefore it
does not follow that they are majority rule.

Marvin Humphrey

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Mar 24, 2015 at 10:28 AM, Jacques Le Roux
<ja...@les7arts.com> wrote:
> Who will update the https://community.apache.org/newcommitter.html page?*

I've done that, it now says "In general, committer elections are
majority approval votes, as described on the Apache Voting Process
page" with a link.

-Bertrand

Re: Veto! Veto?

[Jacques Le Roux <ja...@les7arts.com>]

Who will update the https://community.apache.org/newcommitter.html page?*

This line
     A positive result is achieved by Consensus Approval i.e. at least 3 +1 votes and no vetoes.

I could be wrong but I don't think I can... (not a member)

Thanks

Jacques

Le 24/03/2015 10:11, Pierre Smits a écrit :
> Now that we have that cleared up, we can all go back to our projects and
> contribute the good stuff to our works.
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Mar 24, 2015 at 9:59 AM, Pierre Smits <pi...@gmail.com>
> wrote:
>
>> Having reread the earlier postings I summarise what has been said it as
>> this:
>>
>>
>>     - No vetoes are allowed, when it comes down to procedural issues
>>     (electing persons into functions, e.g. committer, PMC Member, PMC Chair,
>>     etc).
>>        - As stated by Bertrand in his remark that 'A positive result is
>>        achieved by Consensus Approval i.e. at least 3 +1 votes and no vetoes' in
>>        https://community.apache.org/newcommitter.html wrong, because
>>        https://www.apache.org/foundation/voting.html states that voting on
>>        procedural issues follow the common majority rule
>>
>>        I wonder how many projects have stated in their policy (rules of
>>        the games) pages, that they do it differently.
>>        I also wonder how often it happened that - for the projects that
>>        don't state that they do it differently - the common majority rule wasn't
>>        applied when it came to voting regarding a potential committer or PMC
>>        Member.
>>
>>        - Unanimity = consensus wrt procedural issues, as all are for
>>     either for or against what has been voted on. Consensus wrt code-changes
>>     means no vetoes.
>>
>>     - As far as the ASF and the board is concerned, any project under the
>>     ASF umbrella can have the policies its wants/needs and the board is not
>>     going to police that.
>>        - Interpreting the statements made by Rich.
>>           - However the https://www.apache.org/foundations/voting.html is
>>           contradicting that statement in the section about binding votes.
>>
>>
>>           - The statement made by Rich can be interpreted as that a
>>        project can even deviate from any statement made in the voting.html page as
>>        these statements are suggestions based on some kind of arbitrary best
>>        practices. As examples:
>>           - if you want in your project to have it that all contributors
>>           with signed, sent and accepted iCLAs can vote once per year on new
>>           committers and PMC members, then that is acceptable by the ASF and the
>>           board.
>>           - If you want in your project to have it that all contributors
>>           active for 1 year or more can directly vote the PMC Chair every three
>>           years, than that is acceptable by the ASF and the board.
>>           - If you want to have the policy in your project whereby you
>>           want to exclude contributor 'of the other kind' from positions in the
>>           project (committer, PMC Member, PMC Chair), then that is acceptable by the
>>           ASF and the board.
>>
>>
>>
>> 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 Mon, Mar 23, 2015 at 6:41 PM, Mike Kienenberger <mk...@gmail.com>
>> wrote:
>>
>>> On Mon, Mar 23, 2015 at 1:31 PM, Ted Dunning <te...@gmail.com>
>>> wrote:
>>>
>>>>> Here's a better not-quite-so-hypothetical example.   A project like
>>>> MyFaces
>>>>> has to pass the TCK testing suite provided by Oracle.   We would not
>>> want
>>>>> to allow unrestricted commit access by someone who did not
>>>>> understand profoundly and intuitively that the JSF API portion of the
>>>>> project has a predefined public API which cannot be changed.
>>>>
>>>> Some projects feel this way.  Others have found that review is just as
>>>> effective as restricting commit bits tightly.  The classic case is
>>>> Subversion which has a very high profile (and thus is obliged to have
>>>> stable API's).  That PMC offers a commit bit to anyone who asks.
>>>>
>>>> People seem to forget that erroneous commits that pass review can
>>> simply be
>>>> reverted.  That is one of the points of using version control.
>>>>
>>> Yes, either approach could be used.  Myfaces doesn't filter candidates
>>> based on this criteria -- we train contributers when they submit their
>>> first patches to the API project -- but a TCK project might decide to do
>>> so.   The message probably should have read "They might not want to allow"
>>> rather than "We would not want to allow " as it gave the wrong impression.
>>>
>>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

Now that we have that cleared up, we can all go back to our projects and
contribute the good stuff to our works.

Pierre Smits

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

On Tue, Mar 24, 2015 at 9:59 AM, Pierre Smits <pi...@gmail.com>
wrote:

> Having reread the earlier postings I summarise what has been said it as
> this:
>
>
>    - No vetoes are allowed, when it comes down to procedural issues
>    (electing persons into functions, e.g. committer, PMC Member, PMC Chair,
>    etc).
>       - As stated by Bertrand in his remark that 'A positive result is
>       achieved by Consensus Approval i.e. at least 3 +1 votes and no vetoes' in
>       https://community.apache.org/newcommitter.html wrong, because
>       https://www.apache.org/foundation/voting.html states that voting on
>       procedural issues follow the common majority rule
>
>       I wonder how many projects have stated in their policy (rules of
>       the games) pages, that they do it differently.
>       I also wonder how often it happened that - for the projects that
>       don't state that they do it differently - the common majority rule wasn't
>       applied when it came to voting regarding a potential committer or PMC
>       Member.
>
>       - Unanimity = consensus wrt procedural issues, as all are for
>    either for or against what has been voted on. Consensus wrt code-changes
>    means no vetoes.
>
>    - As far as the ASF and the board is concerned, any project under the
>    ASF umbrella can have the policies its wants/needs and the board is not
>    going to police that.
>       - Interpreting the statements made by Rich.
>          - However the https://www.apache.org/foundations/voting.html is
>          contradicting that statement in the section about binding votes.
>
>
>          - The statement made by Rich can be interpreted as that a
>       project can even deviate from any statement made in the voting.html page as
>       these statements are suggestions based on some kind of arbitrary best
>       practices. As examples:
>          - if you want in your project to have it that all contributors
>          with signed, sent and accepted iCLAs can vote once per year on new
>          committers and PMC members, then that is acceptable by the ASF and the
>          board.
>          - If you want in your project to have it that all contributors
>          active for 1 year or more can directly vote the PMC Chair every three
>          years, than that is acceptable by the ASF and the board.
>          - If you want to have the policy in your project whereby you
>          want to exclude contributor 'of the other kind' from positions in the
>          project (committer, PMC Member, PMC Chair), then that is acceptable by the
>          ASF and the board.
>
>
>
> 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 Mon, Mar 23, 2015 at 6:41 PM, Mike Kienenberger <mk...@gmail.com>
> wrote:
>
>> On Mon, Mar 23, 2015 at 1:31 PM, Ted Dunning <te...@gmail.com>
>> wrote:
>>
>> > > Here's a better not-quite-so-hypothetical example.   A project like
>> > MyFaces
>> > > has to pass the TCK testing suite provided by Oracle.   We would not
>> want
>> > > to allow unrestricted commit access by someone who did not
>> > > understand profoundly and intuitively that the JSF API portion of the
>> > > project has a predefined public API which cannot be changed.
>> >
>> >
>> > Some projects feel this way.  Others have found that review is just as
>> > effective as restricting commit bits tightly.  The classic case is
>> > Subversion which has a very high profile (and thus is obliged to have
>> > stable API's).  That PMC offers a commit bit to anyone who asks.
>> >
>> > People seem to forget that erroneous commits that pass review can
>> simply be
>> > reverted.  That is one of the points of using version control.
>> >
>>
>> Yes, either approach could be used.  Myfaces doesn't filter candidates
>> based on this criteria -- we train contributers when they submit their
>> first patches to the API project -- but a TCK project might decide to do
>> so.   The message probably should have read "They might not want to allow"
>> rather than "We would not want to allow " as it gave the wrong impression.
>>
>
>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

Having reread the earlier postings I summarise what has been said it as
this:


   - No vetoes are allowed, when it comes down to procedural issues
   (electing persons into functions, e.g. committer, PMC Member, PMC Chair,
   etc).
      - As stated by Bertrand in his remark that 'A positive result is
      achieved by Consensus Approval i.e. at least 3 +1 votes and no vetoes' in
      https://community.apache.org/newcommitter.html wrong, because
      https://www.apache.org/foundation/voting.html states that voting on
      procedural issues follow the common majority rule

      I wonder how many projects have stated in their policy (rules of the
      games) pages, that they do it differently.
      I also wonder how often it happened that - for the projects that
      don't state that they do it differently - the common majority rule wasn't
      applied when it came to voting regarding a potential committer or PMC
      Member.

      - Unanimity = consensus wrt procedural issues, as all are for either
   for or against what has been voted on. Consensus wrt code-changes means no
   vetoes.

   - As far as the ASF and the board is concerned, any project under the
   ASF umbrella can have the policies its wants/needs and the board is not
   going to police that.
      - Interpreting the statements made by Rich.
         - However the https://www.apache.org/foundations/voting.html is
         contradicting that statement in the section about binding votes.


         - The statement made by Rich can be interpreted as that a project
      can even deviate from any statement made in the voting.html page as these
      statements are suggestions based on some kind of arbitrary best
practices.
      As examples:
         - if you want in your project to have it that all contributors
         with signed, sent and accepted iCLAs can vote once per year on new
         committers and PMC members, then that is acceptable by the ASF and the
         board.
         - If you want in your project to have it that all contributors
         active for 1 year or more can directly vote the PMC Chair every three
         years, than that is acceptable by the ASF and the board.
         - If you want to have the policy in your project whereby you want
         to exclude contributor 'of the other kind' from positions in
the project
         (committer, PMC Member, PMC Chair), then that is acceptable
by the ASF and
         the board.



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 Mon, Mar 23, 2015 at 6:41 PM, Mike Kienenberger <mk...@gmail.com>
wrote:

> On Mon, Mar 23, 2015 at 1:31 PM, Ted Dunning <te...@gmail.com>
> wrote:
>
> > > Here's a better not-quite-so-hypothetical example.   A project like
> > MyFaces
> > > has to pass the TCK testing suite provided by Oracle.   We would not
> want
> > > to allow unrestricted commit access by someone who did not
> > > understand profoundly and intuitively that the JSF API portion of the
> > > project has a predefined public API which cannot be changed.
> >
> >
> > Some projects feel this way.  Others have found that review is just as
> > effective as restricting commit bits tightly.  The classic case is
> > Subversion which has a very high profile (and thus is obliged to have
> > stable API's).  That PMC offers a commit bit to anyone who asks.
> >
> > People seem to forget that erroneous commits that pass review can simply
> be
> > reverted.  That is one of the points of using version control.
> >
>
> Yes, either approach could be used.  Myfaces doesn't filter candidates
> based on this criteria -- we train contributers when they submit their
> first patches to the API project -- but a TCK project might decide to do
> so.   The message probably should have read "They might not want to allow"
> rather than "We would not want to allow " as it gave the wrong impression.
>

Re: Veto! Veto?

[Mike Kienenberger <mk...@gmail.com>]

On Mon, Mar 23, 2015 at 1:31 PM, Ted Dunning <te...@gmail.com> wrote:

> > Here's a better not-quite-so-hypothetical example.   A project like
> MyFaces
> > has to pass the TCK testing suite provided by Oracle.   We would not want
> > to allow unrestricted commit access by someone who did not
> > understand profoundly and intuitively that the JSF API portion of the
> > project has a predefined public API which cannot be changed.
>
>
> Some projects feel this way.  Others have found that review is just as
> effective as restricting commit bits tightly.  The classic case is
> Subversion which has a very high profile (and thus is obliged to have
> stable API's).  That PMC offers a commit bit to anyone who asks.
>
> People seem to forget that erroneous commits that pass review can simply be
> reverted.  That is one of the points of using version control.
>

Yes, either approach could be used.  Myfaces doesn't filter candidates
based on this criteria -- we train contributers when they submit their
first patches to the API project -- but a TCK project might decide to do
so.   The message probably should have read "They might not want to allow"
rather than "We would not want to allow " as it gave the wrong impression.

Re: Veto! Veto?

[Ted Dunning <te...@gmail.com>]

On Mon, Mar 23, 2015 at 9:59 AM, Mike Kienenberger <mk...@gmail.com>
wrote:

> On Mon, Mar 23, 2015 at 12:39 PM, Rich Bowen <rb...@rcbowen.com> wrote:
>
> > The board, and comdev, will say "here's how we think things should go",
> > but there's a lot of room between a mature project like httpd, where
> > someone has 20 years worth of information to read about how to get
> started,
> > and a newer project like, say, Open Climate Workbench, which requires a
> > deep understanding of climate science to contribute meaningfully**, which
> > completely justifies different levels of "barrier to entry" when it comes
> > to inviting committers.
> >
> > ** Note: This is a hypothetical example. I don't actually know anything
> > about OCW. Please don't get bogged down in the example if I'm mistaken.
>
>
> Here's a better not-quite-so-hypothetical example.   A project like MyFaces
> has to pass the TCK testing suite provided by Oracle.   We would not want
> to allow unrestricted commit access by someone who did not
> understand profoundly and intuitively that the JSF API portion of the
> project has a predefined public API which cannot be changed.


Some projects feel this way.  Others have found that review is just as
effective as restricting commit bits tightly.  The classic case is
Subversion which has a very high profile (and thus is obliged to have
stable API's).  That PMC offers a commit bit to anyone who asks.

People seem to forget that erroneous commits that pass review can simply be
reverted.  That is one of the points of using version control.

Re: Veto! Veto?

[Mike Kienenberger <mk...@gmail.com>]

On Mon, Mar 23, 2015 at 12:39 PM, Rich Bowen <rb...@rcbowen.com> wrote:

> The board, and comdev, will say "here's how we think things should go",
> but there's a lot of room between a mature project like httpd, where
> someone has 20 years worth of information to read about how to get started,
> and a newer project like, say, Open Climate Workbench, which requires a
> deep understanding of climate science to contribute meaningfully**, which
> completely justifies different levels of "barrier to entry" when it comes
> to inviting committers.
>
> ** Note: This is a hypothetical example. I don't actually know anything
> about OCW. Please don't get bogged down in the example if I'm mistaken.


Here's a better not-quite-so-hypothetical example.   A project like MyFaces
has to pass the TCK testing suite provided by Oracle.   We would not want
to allow unrestricted commit access by someone who did not
understand profoundly and intuitively that the JSF API portion of the
project has a predefined public API which cannot be changed.

Re: Veto! Veto?

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Mon, Mar 23, 2015 at 9:39 AM, Rich Bowen <rb...@rcbowen.com> wrote:
> If a project decides not to make a certain individual a committer, the Board
> *will not* step in to police that, as you say. It is the project's decision
> who will be a committer.

Right. At the same time if the hypothetical PMC repeatedly fails at fostering
the community by recognizing certain types of merit I will expect the board to
get involved at some point. But! It will expect it to get involved b/c
of the community
shepherding issue, not so much because a procedural guideline has
been violated.

I know this may be irritatingly nebulous (especially to folks who haven't been
around long enough to benefit from the ASF osmosis) but I feel this is
one the key things I *really* like about how ASF is governed.

Thanks,
Roman.

Re: Veto! Veto?

[Rich Bowen <rb...@rcbowen.com>]

On 03/23/2015 05:39 AM, Pierre Smits wrote:
> The ASF defines the boundaries by with the projects are allowed to operate
> under its umbrella. If a project doesn't want to adhere to that, it doesn't
> belong under its umbrella.
>
> If one of its principles or boundaries is community over code and if the
> ASF wants that the diversity within the communities of it projects is
> reflected in the group of committers and in PMC, how can it then be that a
> PMC may have it different and can veto on- and off-boarding of persons of
> the other kind?
>
> And by the way: Yes, it is the task of the ASF (meaning every person within
> the greater community of the ASF, contributor, committer, PMC member, VP
> and etc) to guard that the principles of the ASF are upheld. As it is the
> task of the Board to police.

The board doesn't like to be the police.

The "policy" document that is being cited is what is promoted at the 
Foundation level as best practice, but individual projects are at 
liberty to adopt those guidelines, or not, as long as fundamentals are 
respected.

If a project decides not to make a certain individual a committer, the 
Board *will not* step in to police that, as you say. It is the project's 
decision who will be a committer.

Some projects adopt a "universal committer bit" policy, while others 
have specific guidelines for inviting a committer. And there's 
everything in between. The board is not going to police this.

Your question - "how can it be" - has a simple answer. Because the board 
isn't here to tell projects how to make their technical decisions, and 
inviting a committer is at the heart of technical decisions, because it 
hands those decisions to a new person. The board is not going to tell a 
project how to invite committers.

The board, and comdev, will say "here's how we think things should go", 
but there's a lot of room between a mature project like httpd, where 
someone has 20 years worth of information to read about how to get 
started, and a newer project like, say, Open Climate Workbench, which 
requires a deep understanding of climate science to contribute 
meaningfully**, which completely justifies different levels of "barrier 
to entry" when it comes to inviting committers.

--Rich



** Note: This is a hypothetical example. I don't actually know anything 
about OCW. Please don't get bogged down in the example if I'm mistaken.

-- 
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: Veto! Veto?

[Rich Bowen <rb...@rcbowen.com>]

On 03/23/2015 12:44 PM, Alex Harui wrote:
>
>
> On 3/23/15, 2:39 AM, "Pierre Smits" <pi...@gmail.com> wrote:
>>
>> If one of its principles or boundaries is community over code and if the
>> ASF wants that the diversity within the communities of it projects is
>> reflected in the group of committers and in PMC, how can it then be that a
>> PMC may have it different and can veto on- and off-boarding of persons of
>> the other kind?
>
> A healthy community can have vetoes for people actions and never mis-use
> them.  Vetoes are supposed to have a justification for the veto attached
> to it.  Vetoes based on discrimination should probably result in the
> vetoer getting removed from the PMC if they refuse to rescind their veto.
>
> It sounds like your community should not be allowing vetoes.  Start the
> process of making that change and ask for board support if you need it
> since there is precedent for this very thing.  That newcommitter page cost
> at least one other project some serious time.
>

The board is going to be VERY reluctant to tell a PMC how to invite 
committers. I would almost go so far as to say that the board WILL NOT 
do that, unless there's compelling evidence that the PMC is being 
anti-community in their practices - for example, refusing to select 
committers with particular corporate affiliations, or people of 
particular race/gender/creed.

Yes, a DISCUSS conversation should have resolved difficulties before it 
ever came to a VOTE, and it's regrettable that it didn't. Indeed, it's 
regrettable, in my opinion, that a committer should be vetoed at all. 
But it's not the role of the board to dictate to a project who they 
should give the commit bit to.



-- 
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: Veto! Veto?

[Alex Harui <ah...@adobe.com>]

On 3/23/15, 2:39 AM, "Pierre Smits" <pi...@gmail.com> wrote:
>
>If one of its principles or boundaries is community over code and if the
>ASF wants that the diversity within the communities of it projects is
>reflected in the group of committers and in PMC, how can it then be that a
>PMC may have it different and can veto on- and off-boarding of persons of
>the other kind?

A healthy community can have vetoes for people actions and never mis-use
them.  Vetoes are supposed to have a justification for the veto attached
to it.  Vetoes based on discrimination should probably result in the
vetoer getting removed from the PMC if they refuse to rescind their veto.

It sounds like your community should not be allowing vetoes.  Start the
process of making that change and ask for board support if you need it
since there is precedent for this very thing.  That newcommitter page cost
at least one other project some serious time.

-Alex

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

The ASF defines the boundaries by with the projects are allowed to operate
under its umbrella. If a project doesn't want to adhere to that, it doesn't
belong under its umbrella.

If one of its principles or boundaries is community over code and if the
ASF wants that the diversity within the communities of it projects is
reflected in the group of committers and in PMC, how can it then be that a
PMC may have it different and can veto on- and off-boarding of persons of
the other kind?

And by the way: Yes, it is the task of the ASF (meaning every person within
the greater community of the ASF, contributor, committer, PMC member, VP
and etc) to guard that the principles of the ASF are upheld. As it is the
task of the Board to police.

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 Mon, Mar 23, 2015 at 10:05 AM, jan i <ja...@apache.org> wrote:

> On Monday, March 23, 2015, Pierre Smits <pi...@gmail.com> wrote:
>
> > The principle/policy/rule of the ASF regarding code changes is very
> > explicit, well documented and unambiguous. Can a project's PMC have
> another
> > methodology in place while being part of the ASF? I guess not.
>
>
> not another but always a tougher (e.g. 6+1 no -1).
>
> >
> > Consensus with respect to on and off boarding of people is nice, as it
> > expresses unanimity. And I, as I expect it to be for all, am all for it.
> > But to have it as an requirement would be a show stopper.
> >
> > Would it be ok for the ASF if there were a project under its umbrella,
> that
> > would say: that majority voting principle you for procedural issues is
> > nice, but for us - when it comes to people - we veto
> > promotors/speakers/book writers to participate in our project with
> > privileges (commit right, PMC membership)? Or, that it vetoes people from
> > France (this is example, I have nothing against people from France or
> even
> > with the French nationality)?
> >
> > If the community wants it like that, then there is consensus. It is not
> the task of ASF to police the communities.
>
> We must be very careful only to make ASF wide rules where it is really
> needed e.g. our release policy is there for legal reasons.
>
> 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 Mon, Mar 23, 2015 at 9:20 AM, jan i <jani@apache.org <javascript:;>>
> > wrote:
> >
> > > On 23 March 2015 at 09:02, Pierre Smits <pierre.smits@gmail.com
> > <javascript:;>> wrote:
> > >
> > > > When it comes to people, consensus (acceptance by unanimity) is the
> > best
> > > > thing to have. But if the ASF has as its principle that no vetoes are
> > > > allowed, how can it be the remit of a project's PMC have it as its
> > > policy?
> > > >
> > >
> > > I think it is a matter of wording, I do not think it is a ASF Principle
> > > (actually not sure how that relates to "policy") that veto is not
> > allowed,
> > > Consensus is the ASF Principle. We all want to avoid Vetos, for many
> good
> > > reasons, but that it not the same as not being allowed.
> > >
> > > As a Foundation we try to have very few rules and policies, and let the
> > > communities handle how they want to do it, this here is surely
> > > a case where we do not a foundation wide rule.
> > >
> > > I would have no problem, if the wording on the page was something like
> > "it
> > > is recommended not to use Veto"
> > >
> > > Pierre@ maybe just for my understanding, why would ASF be better, if
> we
> > > make this rule foundation wide, instead of leaving it up to
> > > the single community ?
> > >
> > > 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 Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
> > > > jacques.le.roux@les7arts.com <javascript:;>> wrote:
> > > >
> > > > > Le 22/03/2015 14:42, jan i a écrit :
> > > > >
> > > > >> On 22 March 2015 at 14:35, Pierre Smits <pierre.smits@gmail.com
> > <javascript:;>>
> > > wrote:
> > > > >>
> > > > >>  HI Bertrand,
> > > > >>>
> > > > >>> Thanks for the clarification regarding
> > > > >>> http://community.apache.org/newcommitter.html
> > > > >>>
> > > > >>> Shouldn't http://www.apache.org/foundation/voting.html then also
> > > > >>> explicitly
> > > > >>> reflect that vetoes aren't allowed when it comes to on- and
> > > ofboarding
> > > > >>> contributors as committer and PMC member? That would surely bring
> > > > >>> clarity.
> > > > >>>
> > > > >>>  I would be very unhappy with "aren´t allowed", that is something
> > the
> > > > >> individual PMCs should decide !
> > > > >>
> > > > >
> > > > > Yes indeed that's PMCs 's remit; we just need to clarify the ASF
> > > default.
> > > > >
> > > > > Jacques
> > > > >
> > > > >
> > > > >
> > > > >> 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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
> > > > >>> bdelacretaz@apache.org <javascript:;>
> > > > >>>
> > > > >>>> wrote:
> > > > >>>> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
> > > > >>>> <jacques.le.roux@les7arts.com <javascript:;>> wrote:
> > > > >>>>
> > > > >>>>> ...Thanks for the clarification Bertrand, this was also unclear
> > to
> > > > me.
> > > > >>>>>
> > > > >>>> Should
> > > > >>>>
> > > > >>>>> we not amend the newcommitter page?..
> > > > >>>>>
> > > > >>>> That would be great, I don't have time right now myself.
> > > > >>>> -Bertrand
> > > > >>>>
> > > > >>>>
> > > >
> > >
> >
>
>
> --
> Sent from My iPad, sorry for any misspellings.
>

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On Monday, March 23, 2015, Pierre Smits <pi...@gmail.com> wrote:

> The principle/policy/rule of the ASF regarding code changes is very
> explicit, well documented and unambiguous. Can a project's PMC have another
> methodology in place while being part of the ASF? I guess not.


not another but always a tougher (e.g. 6+1 no -1).

>
> Consensus with respect to on and off boarding of people is nice, as it
> expresses unanimity. And I, as I expect it to be for all, am all for it.
> But to have it as an requirement would be a show stopper.
>
> Would it be ok for the ASF if there were a project under its umbrella, that
> would say: that majority voting principle you for procedural issues is
> nice, but for us - when it comes to people - we veto
> promotors/speakers/book writers to participate in our project with
> privileges (commit right, PMC membership)? Or, that it vetoes people from
> France (this is example, I have nothing against people from France or even
> with the French nationality)?
>
> If the community wants it like that, then there is consensus. It is not
the task of ASF to police the communities.

We must be very careful only to make ASF wide rules where it is really
needed e.g. our release policy is there for legal reasons.

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 Mon, Mar 23, 2015 at 9:20 AM, jan i <jani@apache.org <javascript:;>>
> wrote:
>
> > On 23 March 2015 at 09:02, Pierre Smits <pierre.smits@gmail.com
> <javascript:;>> wrote:
> >
> > > When it comes to people, consensus (acceptance by unanimity) is the
> best
> > > thing to have. But if the ASF has as its principle that no vetoes are
> > > allowed, how can it be the remit of a project's PMC have it as its
> > policy?
> > >
> >
> > I think it is a matter of wording, I do not think it is a ASF Principle
> > (actually not sure how that relates to "policy") that veto is not
> allowed,
> > Consensus is the ASF Principle. We all want to avoid Vetos, for many good
> > reasons, but that it not the same as not being allowed.
> >
> > As a Foundation we try to have very few rules and policies, and let the
> > communities handle how they want to do it, this here is surely
> > a case where we do not a foundation wide rule.
> >
> > I would have no problem, if the wording on the page was something like
> "it
> > is recommended not to use Veto"
> >
> > Pierre@ maybe just for my understanding, why would ASF be better, if we
> > make this rule foundation wide, instead of leaving it up to
> > the single community ?
> >
> > 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 Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
> > > jacques.le.roux@les7arts.com <javascript:;>> wrote:
> > >
> > > > Le 22/03/2015 14:42, jan i a écrit :
> > > >
> > > >> On 22 March 2015 at 14:35, Pierre Smits <pierre.smits@gmail.com
> <javascript:;>>
> > wrote:
> > > >>
> > > >>  HI Bertrand,
> > > >>>
> > > >>> Thanks for the clarification regarding
> > > >>> http://community.apache.org/newcommitter.html
> > > >>>
> > > >>> Shouldn't http://www.apache.org/foundation/voting.html then also
> > > >>> explicitly
> > > >>> reflect that vetoes aren't allowed when it comes to on- and
> > ofboarding
> > > >>> contributors as committer and PMC member? That would surely bring
> > > >>> clarity.
> > > >>>
> > > >>>  I would be very unhappy with "aren´t allowed", that is something
> the
> > > >> individual PMCs should decide !
> > > >>
> > > >
> > > > Yes indeed that's PMCs 's remit; we just need to clarify the ASF
> > default.
> > > >
> > > > Jacques
> > > >
> > > >
> > > >
> > > >> 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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
> > > >>> bdelacretaz@apache.org <javascript:;>
> > > >>>
> > > >>>> wrote:
> > > >>>> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
> > > >>>> <jacques.le.roux@les7arts.com <javascript:;>> wrote:
> > > >>>>
> > > >>>>> ...Thanks for the clarification Bertrand, this was also unclear
> to
> > > me.
> > > >>>>>
> > > >>>> Should
> > > >>>>
> > > >>>>> we not amend the newcommitter page?..
> > > >>>>>
> > > >>>> That would be great, I don't have time right now myself.
> > > >>>> -Bertrand
> > > >>>>
> > > >>>>
> > >
> >
>


-- 
Sent from My iPad, sorry for any misspellings.

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

An opinion poll is not the same as voting on a procedural issue.

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 Mon, Mar 23, 2015 at 9:44 AM, Pierre Smits <pi...@gmail.com>
wrote:

> The principle/policy/rule of the ASF regarding code changes is very
> explicit, well documented and unambiguous. Can a project's PMC have another
> methodology in place while being part of the ASF? I guess not.
>
> Consensus with respect to on and off boarding of people is nice, as it
> expresses unanimity. And I, as I expect it to be for all, am all for it.
> But to have it as an requirement would be a show stopper.
>
> Would it be ok for the ASF if there were a project under its umbrella,
> that would say: that majority voting principle you for procedural issues is
> nice, but for us - when it comes to people - we veto
> promotors/speakers/book writers to participate in our project with
> privileges (commit right, PMC membership)? Or, that it vetoes people from
> France (this is example, I have nothing against people from France or even
> with the French nationality)?
>
> 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 Mon, Mar 23, 2015 at 9:20 AM, jan i <ja...@apache.org> wrote:
>
>> On 23 March 2015 at 09:02, Pierre Smits <pi...@gmail.com> wrote:
>>
>> > When it comes to people, consensus (acceptance by unanimity) is the best
>> > thing to have. But if the ASF has as its principle that no vetoes are
>> > allowed, how can it be the remit of a project's PMC have it as its
>> policy?
>> >
>>
>> I think it is a matter of wording, I do not think it is a ASF Principle
>> (actually not sure how that relates to "policy") that veto is not allowed,
>> Consensus is the ASF Principle. We all want to avoid Vetos, for many good
>> reasons, but that it not the same as not being allowed.
>>
>> As a Foundation we try to have very few rules and policies, and let the
>> communities handle how they want to do it, this here is surely
>> a case where we do not a foundation wide rule.
>>
>> I would have no problem, if the wording on the page was something like "it
>> is recommended not to use Veto"
>>
>> Pierre@ maybe just for my understanding, why would ASF be better, if we
>> make this rule foundation wide, instead of leaving it up to
>> the single community ?
>>
>> 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 Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
>> > jacques.le.roux@les7arts.com> wrote:
>> >
>> > > Le 22/03/2015 14:42, jan i a écrit :
>> > >
>> > >> On 22 March 2015 at 14:35, Pierre Smits <pi...@gmail.com>
>> wrote:
>> > >>
>> > >>  HI Bertrand,
>> > >>>
>> > >>> Thanks for the clarification regarding
>> > >>> http://community.apache.org/newcommitter.html
>> > >>>
>> > >>> Shouldn't http://www.apache.org/foundation/voting.html then also
>> > >>> explicitly
>> > >>> reflect that vetoes aren't allowed when it comes to on- and
>> ofboarding
>> > >>> contributors as committer and PMC member? That would surely bring
>> > >>> clarity.
>> > >>>
>> > >>>  I would be very unhappy with "aren´t allowed", that is something
>> the
>> > >> individual PMCs should decide !
>> > >>
>> > >
>> > > Yes indeed that's PMCs 's remit; we just need to clarify the ASF
>> default.
>> > >
>> > > Jacques
>> > >
>> > >
>> > >
>> > >> 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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
>> > >>> bdelacretaz@apache.org
>> > >>>
>> > >>>> wrote:
>> > >>>> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
>> > >>>> <ja...@les7arts.com> wrote:
>> > >>>>
>> > >>>>> ...Thanks for the clarification Bertrand, this was also unclear to
>> > me.
>> > >>>>>
>> > >>>> Should
>> > >>>>
>> > >>>>> we not amend the newcommitter page?..
>> > >>>>>
>> > >>>> That would be great, I don't have time right now myself.
>> > >>>> -Bertrand
>> > >>>>
>> > >>>>
>> >
>>
>
>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

The principle/policy/rule of the ASF regarding code changes is very
explicit, well documented and unambiguous. Can a project's PMC have another
methodology in place while being part of the ASF? I guess not.

Consensus with respect to on and off boarding of people is nice, as it
expresses unanimity. And I, as I expect it to be for all, am all for it.
But to have it as an requirement would be a show stopper.

Would it be ok for the ASF if there were a project under its umbrella, that
would say: that majority voting principle you for procedural issues is
nice, but for us - when it comes to people - we veto
promotors/speakers/book writers to participate in our project with
privileges (commit right, PMC membership)? Or, that it vetoes people from
France (this is example, I have nothing against people from France or even
with the French nationality)?

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 Mon, Mar 23, 2015 at 9:20 AM, jan i <ja...@apache.org> wrote:

> On 23 March 2015 at 09:02, Pierre Smits <pi...@gmail.com> wrote:
>
> > When it comes to people, consensus (acceptance by unanimity) is the best
> > thing to have. But if the ASF has as its principle that no vetoes are
> > allowed, how can it be the remit of a project's PMC have it as its
> policy?
> >
>
> I think it is a matter of wording, I do not think it is a ASF Principle
> (actually not sure how that relates to "policy") that veto is not allowed,
> Consensus is the ASF Principle. We all want to avoid Vetos, for many good
> reasons, but that it not the same as not being allowed.
>
> As a Foundation we try to have very few rules and policies, and let the
> communities handle how they want to do it, this here is surely
> a case where we do not a foundation wide rule.
>
> I would have no problem, if the wording on the page was something like "it
> is recommended not to use Veto"
>
> Pierre@ maybe just for my understanding, why would ASF be better, if we
> make this rule foundation wide, instead of leaving it up to
> the single community ?
>
> 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 Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
> > jacques.le.roux@les7arts.com> wrote:
> >
> > > Le 22/03/2015 14:42, jan i a écrit :
> > >
> > >> On 22 March 2015 at 14:35, Pierre Smits <pi...@gmail.com>
> wrote:
> > >>
> > >>  HI Bertrand,
> > >>>
> > >>> Thanks for the clarification regarding
> > >>> http://community.apache.org/newcommitter.html
> > >>>
> > >>> Shouldn't http://www.apache.org/foundation/voting.html then also
> > >>> explicitly
> > >>> reflect that vetoes aren't allowed when it comes to on- and
> ofboarding
> > >>> contributors as committer and PMC member? That would surely bring
> > >>> clarity.
> > >>>
> > >>>  I would be very unhappy with "aren´t allowed", that is something the
> > >> individual PMCs should decide !
> > >>
> > >
> > > Yes indeed that's PMCs 's remit; we just need to clarify the ASF
> default.
> > >
> > > Jacques
> > >
> > >
> > >
> > >> 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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
> > >>> bdelacretaz@apache.org
> > >>>
> > >>>> wrote:
> > >>>> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
> > >>>> <ja...@les7arts.com> wrote:
> > >>>>
> > >>>>> ...Thanks for the clarification Bertrand, this was also unclear to
> > me.
> > >>>>>
> > >>>> Should
> > >>>>
> > >>>>> we not amend the newcommitter page?..
> > >>>>>
> > >>>> That would be great, I don't have time right now myself.
> > >>>> -Bertrand
> > >>>>
> > >>>>
> >
>

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On 23 March 2015 at 09:02, Pierre Smits <pi...@gmail.com> wrote:

> When it comes to people, consensus (acceptance by unanimity) is the best
> thing to have. But if the ASF has as its principle that no vetoes are
> allowed, how can it be the remit of a project's PMC have it as its policy?
>

I think it is a matter of wording, I do not think it is a ASF Principle
(actually not sure how that relates to "policy") that veto is not allowed,
Consensus is the ASF Principle. We all want to avoid Vetos, for many good
reasons, but that it not the same as not being allowed.

As a Foundation we try to have very few rules and policies, and let the
communities handle how they want to do it, this here is surely
a case where we do not a foundation wide rule.

I would have no problem, if the wording on the page was something like "it
is recommended not to use Veto"

Pierre@ maybe just for my understanding, why would ASF be better, if we
make this rule foundation wide, instead of leaving it up to
the single community ?

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 Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > Le 22/03/2015 14:42, jan i a écrit :
> >
> >> On 22 March 2015 at 14:35, Pierre Smits <pi...@gmail.com> wrote:
> >>
> >>  HI Bertrand,
> >>>
> >>> Thanks for the clarification regarding
> >>> http://community.apache.org/newcommitter.html
> >>>
> >>> Shouldn't http://www.apache.org/foundation/voting.html then also
> >>> explicitly
> >>> reflect that vetoes aren't allowed when it comes to on- and ofboarding
> >>> contributors as committer and PMC member? That would surely bring
> >>> clarity.
> >>>
> >>>  I would be very unhappy with "aren´t allowed", that is something the
> >> individual PMCs should decide !
> >>
> >
> > Yes indeed that's PMCs 's remit; we just need to clarify the ASF default.
> >
> > Jacques
> >
> >
> >
> >> 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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
> >>> bdelacretaz@apache.org
> >>>
> >>>> wrote:
> >>>> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
> >>>> <ja...@les7arts.com> wrote:
> >>>>
> >>>>> ...Thanks for the clarification Bertrand, this was also unclear to
> me.
> >>>>>
> >>>> Should
> >>>>
> >>>>> we not amend the newcommitter page?..
> >>>>>
> >>>> That would be great, I don't have time right now myself.
> >>>> -Bertrand
> >>>>
> >>>>
>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

When it comes to people, consensus (acceptance by unanimity) is the best
thing to have. But if the ASF has as its principle that no vetoes are
allowed, how can it be the remit of a project's PMC have it as its policy?

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 Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Le 22/03/2015 14:42, jan i a écrit :
>
>> On 22 March 2015 at 14:35, Pierre Smits <pi...@gmail.com> wrote:
>>
>>  HI Bertrand,
>>>
>>> Thanks for the clarification regarding
>>> http://community.apache.org/newcommitter.html
>>>
>>> Shouldn't http://www.apache.org/foundation/voting.html then also
>>> explicitly
>>> reflect that vetoes aren't allowed when it comes to on- and ofboarding
>>> contributors as committer and PMC member? That would surely bring
>>> clarity.
>>>
>>>  I would be very unhappy with "aren´t allowed", that is something the
>> individual PMCs should decide !
>>
>
> Yes indeed that's PMCs 's remit; we just need to clarify the ASF default.
>
> Jacques
>
>
>
>> 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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
>>> bdelacretaz@apache.org
>>>
>>>> wrote:
>>>> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
>>>> <ja...@les7arts.com> wrote:
>>>>
>>>>> ...Thanks for the clarification Bertrand, this was also unclear to me.
>>>>>
>>>> Should
>>>>
>>>>> we not amend the newcommitter page?..
>>>>>
>>>> That would be great, I don't have time right now myself.
>>>> -Bertrand
>>>>
>>>>

Re: Veto! Veto?

[Jacques Le Roux <ja...@les7arts.com>]

Le 22/03/2015 14:42, jan i a écrit :
> On 22 March 2015 at 14:35, Pierre Smits <pi...@gmail.com> wrote:
>
>> HI Bertrand,
>>
>> Thanks for the clarification regarding
>> http://community.apache.org/newcommitter.html
>>
>> Shouldn't http://www.apache.org/foundation/voting.html then also
>> explicitly
>> reflect that vetoes aren't allowed when it comes to on- and ofboarding
>> contributors as committer and PMC member? That would surely bring clarity.
>>
> I would be very unhappy with "aren´t allowed", that is something the
> individual PMCs should decide !

Yes indeed that's PMCs 's remit; we just need to clarify the ASF default.

Jacques

>
> 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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
>> bdelacretaz@apache.org
>>> wrote:
>>> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
>>> <ja...@les7arts.com> wrote:
>>>> ...Thanks for the clarification Bertrand, this was also unclear to me.
>>> Should
>>>> we not amend the newcommitter page?..
>>> That would be great, I don't have time right now myself.
>>> -Bertrand
>>>

Re: Veto! Veto?

[jan i <ja...@apache.org>]

On 22 March 2015 at 14:35, Pierre Smits <pi...@gmail.com> wrote:

> HI Bertrand,
>
> Thanks for the clarification regarding
> http://community.apache.org/newcommitter.html
>
> Shouldn't http://www.apache.org/foundation/voting.html then also
> explicitly
> reflect that vetoes aren't allowed when it comes to on- and ofboarding
> contributors as committer and PMC member? That would surely bring clarity.
>

I would be very unhappy with "aren´t allowed", that is something the
individual PMCs should decide !

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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> > wrote:
>
> > On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
> > <ja...@les7arts.com> wrote:
> > > ...Thanks for the clarification Bertrand, this was also unclear to me.
> > Should
> > > we not amend the newcommitter page?..
> >
> > That would be great, I don't have time right now myself.
> > -Bertrand
> >
>

Re: Veto! Veto?

[Pierre Smits <pi...@gmail.com>]

HI Bertrand,

Thanks for the clarification regarding
http://community.apache.org/newcommitter.html

Shouldn't http://www.apache.org/foundation/voting.html then also explicitly
reflect that vetoes aren't allowed when it comes to on- and ofboarding
contributors as committer and PMC member? That would surely bring clarity.

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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:

> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
> <ja...@les7arts.com> wrote:
> > ...Thanks for the clarification Bertrand, this was also unclear to me.
> Should
> > we not amend the newcommitter page?..
>
> That would be great, I don't have time right now myself.
> -Bertrand
>

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux
<ja...@les7arts.com> wrote:
> ...Thanks for the clarification Bertrand, this was also unclear to me. Should
> we not amend the newcommitter page?..

That would be great, I don't have time right now myself.
-Bertrand

Re: Veto! Veto?

[Jacques Le Roux <ja...@les7arts.com>]

Le 22/03/2015 13:56, Bertrand Delacretaz a écrit :
> Hi,
>
> On Sat, Mar 21, 2015 at 2:04 AM, Pierre Smits <pi...@gmail.com> wrote:
>> ...The following document https://community.apache.org/newcommitter.html
>> states:
>>
>> A positive result is achieved by Consensus Approval i.e. at least 3 +1
>> votes and no vetoes....
> There are no vetoes when electing committers, that document is wrong.
>
> https://www.apache.org/foundation/voting.html is the canonical
> document about Apache votes, it specifies vetoes only for code
> commits.
>
> -Bertrand
>

Thanks for the clarification Bertrand, this was also unclear to me. Should we not amend the newcommitter page?

Thanks

Jacques

Re: Veto! Veto?

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Sat, Mar 21, 2015 at 2:04 AM, Pierre Smits <pi...@gmail.com> wrote:
> ...The following document https://community.apache.org/newcommitter.html
> states:
>
> A positive result is achieved by Consensus Approval i.e. at least 3 +1
> votes and no vetoes....

There are no vetoes when electing committers, that document is wrong.

https://www.apache.org/foundation/voting.html is the canonical
document about Apache votes, it specifies vetoes only for code
commits.

-Bertrand

Re: Veto! Veto?

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, Mar 20, 2015 at 6:04 PM, Pierre Smits <pi...@gmail.com> wrote:

> Wouldn't a simple majority (more +1 than -1 votes) yield the same result?

Majority rule votes degrade community.  Whenever you have a contended vote,
you produce losers who feel alienated[1].  In contrast, consensus decision
making forces the majority to take account of minority opinions.  The
negotiation process may frustrate everyone to some extent, but it's less
exclusionary.

Avoiding majority rule and preferring consensus is one of the fundamental
design decisions which have made Apache successful.  The same community might
well produce different solutions to the same problem depending on the rules
for resolving conflict.

In the case of a VOTE to invite a new PMC member, there's no way to negotiate
an alternative solution to take into account the concerns of the minority.
However, those in favor will have to account for those concerns and those
opposed will need to defend their stance.  The act of talking things through
should help to keep the community whole.

Marvin Humphrey

[1] Anime explanation of how majority-rule voting alienates the minority:
    http://www.crunchyroll.com/hunter-x-hunter/episode-10-trick-x-to-the-x-trick-585058?t=429
    (Warning: autoplay video and multiple ads before the content starts)

Re: Veto! Veto?

[Shane Curcuru <as...@shanecurcuru.org>]

On 3/20/15 9:04 PM, Pierre Smits wrote:
> Hi all,
> 
> If I understand the various documents/pages available regarding voting
> correctly, voting a new member in can't be vetoed. Likewise is it with
> respect to voting for board members. If I have missed a page somewhere,
> please point me to it and I stand corrected.

Board and new Member voting at the Foundation level are clearly
documented - note that these are specific procedures that are
*different* from best practices for PMC voting on new committers.

  https://wiki.apache.org/general/MemberVoting
  https://wiki.apache.org/general/BoardVoting

In particular since the Board voting process uses STV there are only
positive votes, no negative votes for candidates (obviously, you can
withhold voting from some candidates).

> 
> The following document https://community.apache.org/newcommitter.html
> states:

That also notes at the top:

"Each project has different approaches to managing new committers, this
page describes a common process found in many Apache projects"

It is important to have best practices for all projects, and for
projects to document their own specific ways to make decisions.  But the
bigger point is to work towards a consensus among the active
contributing PMC members and/or committers within a project.

In many cases, a key way to make this a smoother process is ensuring you
hold a [DISCUSS] thread about "hey, I'm thinking of nominating X for
committer" first.  IF there are objections during the discussion that
some people can clearly explain, you usually put things on hold for a
period to see if whatever is being objected too can be corrected.

- Shane

> 
> A positive result is achieved by Consensus Approval i.e. at least 3 +1
> votes and no vetoes.
> 
> Any veto must be accompanied by reasoning and be prepared to defend it.
> Other members can attempt to encourage them to change.
> 
> While this document talks about getting new committers in a project, it
> also seem to be applicable when it comes to getting new PMC members and
> even who chairs the PMC.
> 
> So how can it be that when it comes to projects, vetoes can be expressed
> and block innovation or growth?
> One of the reasons I heard when discussing this was that it establishes
> control or manageability of the projects member list.
> 
> Wouldn't a simple majority (more +1 than -1 votes) yield the same result?
> If someone would feel that non-acceptance of a new person would benefit the
> project, wouldn’t it be more proper/righteous  that he should put in the
> effort and get a majority of votes?
> 
> It is understandable why the ASF (and its projects) have the veto principle
> regarding code changes as it ensures that the(released) works of the
> project are of a higher quality than the previous work, and that the works
> don't change to something else than what is stated in the mission of the
> project (meaning that e.g. the primary work of the Apache HTTP project -
> httpd can't be converted into e.g. foo widget).
> When it comes to people (and organisations), vetoes have proven that it is
> a means to force consensus into a certain direction. It might have some
> valid grounds when only a few have the biggest gun and they want to keep
> others from getting the same gun (and thus rights/power), but in a
> environment (as the ASF is) that builds on collaboration it is seems
> overkill.
> 
> What do you think? Is, when it comes to people, the veto mechanism not out
> of place for an ASF project?
> 
> 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
>