community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: Veto! Veto?
Date Sat, 21 Mar 2015 15:26:18 GMT
On 21 March 2015 at 15:24, Pierre Smits <pierre.smits@gmail.com> wrote:

> Again, this is not about the veto mechanism for the technical works of the
> project. This is about onboarding of new people, this is about community
> development.
>
> Voting is not a technicality or formality when it comes to people. It is
> the ultimate means to get to a resolution. We can discuss all we want, but
> there are times when discussing doesn't lead to some kind of resolution
> (consensus or implicit acceptance). When the discussion heats up, it often
> leads to 'I am right and you are wrong' to and fro. When that happens
> voting will bring a resolution. But then a veto is the ultimate 'my way and
> I won't budge' variant in stead of seeking the compromise. In the case of
> people (both onboarding and offboarding) it doesn't help to move a project
> forward. It is a postponer, a show stopper.
>
> In a posting above it said that the PMC of a project is free to define it
> own ruleset regarding the way that project operates. But that freedom is
> bound by the principles of the Apache Software Foundation. Principles (and
> changes thereon) that are voted upon by the members of the ASF. This
> platform is the place to discuss the aspects of community development in a
> broader sense. Like we did when the topic of the project maturity model
> came up. This is another topic in that broader sense of building mature
> projects.
>
you are right this is the platform to discuss these matters, but you are
wrong that there is
a policy or principle that the vote for new committers/need to allow a veto.

What you refer to is a recommendation ! Is you follow projects you will
from time to time
see projects forward a suggested PMC extension to the board (Board has to
acknowledge
every PMC extension, with a 72 hour delay) without having had a vote, but
just refer to
a consensus thread.

So I do not understand the problem, if your PMC wants not to include veto
in PMC/Committer go
ahead and do so. My personal opinion (my policy or ...) is that if a PMC
have had a discussion and then
someone gives a -1 in the vote, there is a community problem not a policy
problem.


>
> Why the need to talk specifics? This is not about finger pointing or naming
> and shaming. And if it were, it shouldn't be done here but in a private
> message to the board. And I trust that the board has ample means to take
> appropriate actions.
>
Sorry it was not to offend you, but simply to get a better understanding of
what the problem really is,
as said above if your PMC does not like veto then donĀ“t use it, nobody
forces you to use it.

If the problem is you want to change the recommendation, then it might be a
good idea to talk about a
specific change to a specific page.

rgds
jan I.


>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sat, Mar 21, 2015 at 2:42 PM, Mike Kienenberger <mkienenb@gmail.com>
> wrote:
>
> > Have you read https://www.apache.org/foundation/voting.html?
> >
> > As others have said, the idea is always to build consensus rather than
> > force a result.   I guess I've been fortunate in that the projects in
> > which I've been most active have always been more interested in
> > consensus than individuals forcing a result.   This does add what
> > seems to be a bit of bureaucracy at first glance.  For example, we
> > "vote" about taking a vote for committers and PMC members (others
> > above have called it "DISCUSS").   And if we aren't going to be
> > unanimous in our decision to add in a new committer or PMC member,
> > then we've always decided to postpone the vote until the individual
> > overcomes whatever caused the objection.
> >
> > I think the reason that code commits can be vetoed is to prevent
> > dangerous situations.  Projects can't afford to delay dealing with
> > security issues or licensing issues.   I've been on the PMC for two
> > different projects for a decade, and to my recollection we've never
> > had a code veto.   As far as I know, there's only been a threat of a
> > veto one time in those 20 project-years of time, and it was by me.  I
> > used the threat of veto with a specific committer who had been asked
> > before to not make behavioral changes to the code in the same commit
> > where he reformatted every line of the file.   It was making it
> > impossible to review his code changes.
> >
> > Veto is there for emergencies, not for bending others to your technical
> > vision.
> >
> > And yes, we've had some disagreements about how things should be done
> > technically, but the final decision usually came down to either "I'm
> > willing to do the work" or putting it on hold.
> >
> >
> > On Sat, Mar 21, 2015 at 7:00 AM, Pierre Smits <pierre.smits@gmail.com>
> > wrote:
> > > If the majority perceives that a nominee is an obstructionist then it
> > will
> > > be reflected in the voting result. But if the minority - or even only
> one
> > > voter - perceives that and others don't, then a veto would be a show
> > > stopper for innovation, expansion and merit recognition c.q. privilege
> > > awarding.
> > >
> > > I wonder how it can be that democracy is perceived worse than any other
> > > cracy when it comes to people in open source projects in general and
> ASF
> > > projects in particular. Mature projects shouldn't need to have such a
> > > mechanism when it comes to people. And it doesn't seem to fit in he
> > Apache
> > > Way.
> > >
> > > Best regards
> > >
> > >
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM <http://www.orrtiz.com>*
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Sat, Mar 21, 2015 at 5:24 AM, Alex Harui <aharui@adobe.com> wrote:
> > >
> > >> Consensus Approval works great until you have someone who others
> rightly
> > >> or wrongly perceive as an obstructionist.  Then it just makes the
> whole
> > >> project the loser.
> > >>
> > >> At least one project uses majority approval for new members, but a
> > serious
> > >> attempt is made to make sure that the vote is unanimous anyway.  Those
> > in
> > >> opposition deserve to be listened to, but if there are only one or two
> > >> against and lots more in favor, then majority approval avoids long
> > threads
> > >> trying to persuade the one or two.  Sure discussing more to achieve
> > >> Consensus can be better, but you can also lose momentum of the
> committer
> > >> candidate and momentum of the rest of the community.
> > >>
> > >> The -1 vote is an alluring drug.  It can be misused by individuals
> who,
> > >> consciously or not, cannot avoid the temptation to have control rather
> > >> than to collaborate.  But really make sure you listen.  History is
> full
> > of
> > >> disasters caused by not listening to that one person.
> > >>
> > >> -Alex
> > >>
> > >>
> >
>

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