You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Alex Harui <ah...@adobe.com> on 2014/09/26 05:59:45 UTC
Committer Voting and Vetos
In a past discussion about by-laws, some folks were adamant that voting
for new committer and PMC members be consensus votes so a single person
can block the adding of a candidate.
Do any projects use some form of majority voting for new committers? What
are the reasons for allowing vetoes?
Thanks,
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Committer Voting and Vetos
Posted by Brett Porter <br...@apache.org>.
As an additional reference, here's a previous thread on the topic:
http://mail-archives.apache.org/mod_mbox/incubator-general/201303.mbox/%3CCAPFNckiJy6TM5tYCfN7mScH6h0v_eaR7ws5QMfTEGaoo+DoktQ@mail.gmail.com%3E
Cheers,
Brett
On 26 Sep 2014, at 1:59 pm, Alex Harui <ah...@adobe.com> wrote:
> In a past discussion about by-laws, some folks were adamant that voting
> for new committer and PMC members be consensus votes so a single person
> can block the adding of a candidate.
>
> Do any projects use some form of majority voting for new committers? What
> are the reasons for allowing vetoes?
>
> Thanks,
> -Alex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Committer Voting and Vetos
Posted by Jake Farrell <jf...@apache.org>.
Hey Alex
If during a new committer vote someone is giving a negative vote then the
reasoning should be included with that vote and a discussion can follow
around why the person was given the negative vote, this should all occur on
the private@ mailing list for that project. If there is hesitation about a
new committer then it should be brought out into the open and vetted and
the veto should not just be glossed over and ignored
-Jake
On Thu, Sep 25, 2014 at 11:59 PM, Alex Harui <ah...@adobe.com> wrote:
> In a past discussion about by-laws, some folks were adamant that voting
> for new committer and PMC members be consensus votes so a single person
> can block the adding of a candidate.
>
> Do any projects use some form of majority voting for new committers? What
> are the reasons for allowing vetoes?
>
> Thanks,
> -Alex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Committer Voting and Vetos
Posted by David Nalley <da...@gnsa.us>.
On Thu, Sep 25, 2014 at 11:59 PM, Alex Harui <ah...@adobe.com> wrote:
> In a past discussion about by-laws, some folks were adamant that voting
> for new committer and PMC members be consensus votes so a single person
> can block the adding of a candidate.
>
> Do any projects use some form of majority voting for new committers? What
> are the reasons for allowing vetoes?
>
> Thanks,
> -Alex
>
I'd personally ask this question on dev@community.a.o instead of here,
but I'll weigh in here.
In general we operate on consensus.
I personally think the single person veto for allowing in new
committers/PMC members is important; perhaps more important than veto
on technical issues. Community over code and all - if I'm willing to
trust someone with the ability to veto a technical decision, that
isn't remotely as important as a community decision, then I should
also trust them with a veto on adding committers or PMC members
because it's even more crucial to the project. It's not problem free -
and could be subject to abuse (one of the reasons to be careful who
you let in.) but a reasonable approach.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Committer Voting and Vetos
Posted by jan i <ja...@apache.org>.
On 26 September 2014 19:43, Noah Slater <ns...@apache.org> wrote:
> Another way of wording this would be: the CouchDB community feels that for
> non-technical decisions, a single -1 vote should never block a majority
> consensus. The idea being that if the reasons for the -1 vote were
> compelling enough, others would change their position.
>
> It happened recently on a PMC I sit on. Many people were in favour of an
> action, and one person was against. The action was blocked.
>
> If this happens regularly enough, you can end up never taking any actions.
>
> Of course, how close to absolute consensus you want to require depends on
> two things:
>
> - The nature of the decision
> - The shape of your community
>
> For young projects, I would recommend being strict, and then loosening up
> if you start to have problems.
>
I think this is the key, start strict, and loosen up where really needed as
the project get more mature.
just my 2ct
jan I.
>
>
>
> On Friday, 26 September 2014, Noah Slater <ns...@apache.org> wrote:
>
> > As the primary author of the CouchDB bylaws, I will weigh in here.
> >
> > Agree with Ross on the discussion stuff. We actually codify this
> > attitude in our bylaws.
> >
> > http://couchdb.apache.org/bylaws.html#decisions
> >
> > Specifically, we (CouchDB) see voting as the failure mode of a
> > discussion (a useful one non-the-less), or as a last-step requirement
> > to officiate a particular set of project-level decisions (that are
> > fully enumerated in the bylaws).
> >
> > Wrt to the approval model of voting in committers...
> >
> > cf. http://couchdb.apache.org/bylaws.html#approval
> >
> > We chose lazy 2/3 majority, i.e. requires three binding +1 votes and
> > twice as many binding +1 votes as binding -1 votes.
> >
> > Very specifically (and this is spelled out in the bylaws) with the
> > CouchDB project, we only want a -1 vote to have veto power within the
> > context of code review on a release branch.
> >
> > There are historical reasons for this. We found that some members of
> > our community were casting -1 votes fairly carelessly, and expecting
> > to be able to halt what the majority of the PMC felt were beneficial
> > initiatives (including elections).
> >
> > For us, moving to lazy majority or lazy 2/3 majority for most big
> > decisions was a way to improve our decision-making ability, allowing
> > us to actually make changes to the project, whereas before we had been
> > quite sclerotic.
> >
> > As Joe correctly hits on, some of this was due to me and others
> > attempting to make some fairly large changes to the project since
> > about 2012, when we ran into some major issues.
> >
> > One of the changes I was driving was the redefinition of what a
> > committer is. I wanted to lower the barrier to entry. Whereas before
> > we tended to only elect people who were contributing code, I wanted to
> > expand that and start electing people who were doing other things,
> > like documentation, translation, marketing, design, community
> > management, and so on.
> >
> > This is just one example. But making these sorts of changes
> > (essentially things that require cultural shifts) is hard when one
> > person is able cast a -1 vote and shut down an initiative that
> > everyone else is behind.
> >
> >
> >
> > On 26 September 2014 16:46, Ross Gardler (MS OPEN TECH)
> > <Ross.Gardler@microsoft.com <javascript:;>> wrote:
> > > Trying to build on Joes answer below....
> > >
> > > Given that the ASF is about consensus the vote for.at should be mostly
> > irrelevant. Nominations should have been thoroughly discussed before the
> > vote is called. The vote should be a formality required by the bylaws to
> > demonstrate consensus.
> > >
> > > What I mean is there should never be a veto vote cast. The PMC should
> > have already discussed the reasons why someone has their concerns. Those
> > reasons should either have been supported (and no vote called) or talked
> > through and withdrawn.
> > >
> > > An example... An individual was proposed, the PMC discussed. Two people
> > felt it was too early because the individual had bit contributed much
> code,
> > and thus their code quality could bit be assessed. Everyone recognized
> the
> > individual was contributing to user support, documentation, design etc.
> In
> > order to have the objections removed a PMC member offered to mentor the
> new
> > committee should code contributions prove to be problematic. This
> approach
> > was agreed, the vote was called and passed.
> > >
> > > That individual is now a member of the foundation. Had we bot brought
> > then in at the earliest opportunity they may never have become so
> invested
> > in the foundation and its projects.
> > >
> > > Sometimes it's not possible to reach unanimous consensus. In such
> > situations the community needs to delay the vote (they agree the concerns
> > are appropriate) or they use voting to break the deadlock. How the vote
> is
> > conducted is covered well by Joe.
> > >
> > > Sent from my Windows Phone
> > > ________________________________
> > > From: Joe Brockmeier<mailto:jzb@zonker.net <javascript:;>>
> > > Sent: 9/26/2014 5:00 AM
> > > To: general@incubator.apache.org <javascript:;><mailto:
> > general@incubator.apache.org <javascript:;>>
> > > Subject: Re: Committer Voting and Vetos
> > >
> > > On Thu, Sep 25, 2014, at 10:59 PM, Alex Harui wrote:
> > >> In a past discussion about by-laws, some folks were adamant that
> voting
> > >> for new committer and PMC members be consensus votes so a single
> person
> > >> can block the adding of a candidate.
> > >>
> > >> Do any projects use some form of majority voting for new committers?
> > >> What are the reasons for allowing vetoes?
> > >
> > > Yes, some projects have lazy majority/no veto for committer votes.
> > > CouchDB for example:
> > >
> > > http://couchdb.apache.org/bylaws.html
> > >
> > > Some reasons I'd give in favor of the veto model:
> > >
> > > * Consensus on decisions around new committers/PMC members is pretty
> > > important. A majority vote that overrides concerns of one or more PMC
> > > members rather than working through those concerns may not be good for
> > > the community.
> > >
> > > * You can usually re-visit a discussion to vote on a new committer or
> > > PMC member, but once they're voted on it's more difficult to undo it.
> If
> > > the no voter(s) are saying "not yet convinced," giving some additional
> > > time to work that out may be better for the community than forcing it
> > > and later regretting it.
> > >
> > > Reason *not* to have a veto:
> > >
> > > * It could be abused, or simply cause harm to a community because one
> or
> > > more PMC members are too conservative about adding new committers.
> > > Contributors lose interest and the community stagnates.
> > >
> > > [Other folks probably have different reasons they'd give in favor of or
> > > against vetoes, many of whom have been around much longer than I -- so
> I
> > > hope others will chime in as well.]
> > >
> > > Generally, I lean towards having a veto. If one member has a real
> > > concern, I'd prefer to see it worked through and achieve consensus
> > > rather than overriding someone.
> > >
> > > Best,
> > >
> > > jzb
> > > --
> > > Joe Brockmeier
> > > jzb@zonker.net <javascript:;>
> > > Twitter: @jzb
> > > http://www.dissociatedpress.net/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > <javascript:;>
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > <javascript:;>
> > >
> >
> >
> >
> > --
> > Noah Slater
> > https://twitter.com/nslater
> >
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>
Re: Committer Voting and Vetos
Posted by Noah Slater <ns...@apache.org>.
Another way of wording this would be: the CouchDB community feels that for
non-technical decisions, a single -1 vote should never block a majority
consensus. The idea being that if the reasons for the -1 vote were
compelling enough, others would change their position.
It happened recently on a PMC I sit on. Many people were in favour of an
action, and one person was against. The action was blocked.
If this happens regularly enough, you can end up never taking any actions.
Of course, how close to absolute consensus you want to require depends on
two things:
- The nature of the decision
- The shape of your community
For young projects, I would recommend being strict, and then loosening up
if you start to have problems.
On Friday, 26 September 2014, Noah Slater <ns...@apache.org> wrote:
> As the primary author of the CouchDB bylaws, I will weigh in here.
>
> Agree with Ross on the discussion stuff. We actually codify this
> attitude in our bylaws.
>
> http://couchdb.apache.org/bylaws.html#decisions
>
> Specifically, we (CouchDB) see voting as the failure mode of a
> discussion (a useful one non-the-less), or as a last-step requirement
> to officiate a particular set of project-level decisions (that are
> fully enumerated in the bylaws).
>
> Wrt to the approval model of voting in committers...
>
> cf. http://couchdb.apache.org/bylaws.html#approval
>
> We chose lazy 2/3 majority, i.e. requires three binding +1 votes and
> twice as many binding +1 votes as binding -1 votes.
>
> Very specifically (and this is spelled out in the bylaws) with the
> CouchDB project, we only want a -1 vote to have veto power within the
> context of code review on a release branch.
>
> There are historical reasons for this. We found that some members of
> our community were casting -1 votes fairly carelessly, and expecting
> to be able to halt what the majority of the PMC felt were beneficial
> initiatives (including elections).
>
> For us, moving to lazy majority or lazy 2/3 majority for most big
> decisions was a way to improve our decision-making ability, allowing
> us to actually make changes to the project, whereas before we had been
> quite sclerotic.
>
> As Joe correctly hits on, some of this was due to me and others
> attempting to make some fairly large changes to the project since
> about 2012, when we ran into some major issues.
>
> One of the changes I was driving was the redefinition of what a
> committer is. I wanted to lower the barrier to entry. Whereas before
> we tended to only elect people who were contributing code, I wanted to
> expand that and start electing people who were doing other things,
> like documentation, translation, marketing, design, community
> management, and so on.
>
> This is just one example. But making these sorts of changes
> (essentially things that require cultural shifts) is hard when one
> person is able cast a -1 vote and shut down an initiative that
> everyone else is behind.
>
>
>
> On 26 September 2014 16:46, Ross Gardler (MS OPEN TECH)
> <Ross.Gardler@microsoft.com <javascript:;>> wrote:
> > Trying to build on Joes answer below....
> >
> > Given that the ASF is about consensus the vote for.at should be mostly
> irrelevant. Nominations should have been thoroughly discussed before the
> vote is called. The vote should be a formality required by the bylaws to
> demonstrate consensus.
> >
> > What I mean is there should never be a veto vote cast. The PMC should
> have already discussed the reasons why someone has their concerns. Those
> reasons should either have been supported (and no vote called) or talked
> through and withdrawn.
> >
> > An example... An individual was proposed, the PMC discussed. Two people
> felt it was too early because the individual had bit contributed much code,
> and thus their code quality could bit be assessed. Everyone recognized the
> individual was contributing to user support, documentation, design etc. In
> order to have the objections removed a PMC member offered to mentor the new
> committee should code contributions prove to be problematic. This approach
> was agreed, the vote was called and passed.
> >
> > That individual is now a member of the foundation. Had we bot brought
> then in at the earliest opportunity they may never have become so invested
> in the foundation and its projects.
> >
> > Sometimes it's not possible to reach unanimous consensus. In such
> situations the community needs to delay the vote (they agree the concerns
> are appropriate) or they use voting to break the deadlock. How the vote is
> conducted is covered well by Joe.
> >
> > Sent from my Windows Phone
> > ________________________________
> > From: Joe Brockmeier<mailto:jzb@zonker.net <javascript:;>>
> > Sent: 9/26/2014 5:00 AM
> > To: general@incubator.apache.org <javascript:;><mailto:
> general@incubator.apache.org <javascript:;>>
> > Subject: Re: Committer Voting and Vetos
> >
> > On Thu, Sep 25, 2014, at 10:59 PM, Alex Harui wrote:
> >> In a past discussion about by-laws, some folks were adamant that voting
> >> for new committer and PMC members be consensus votes so a single person
> >> can block the adding of a candidate.
> >>
> >> Do any projects use some form of majority voting for new committers?
> >> What are the reasons for allowing vetoes?
> >
> > Yes, some projects have lazy majority/no veto for committer votes.
> > CouchDB for example:
> >
> > http://couchdb.apache.org/bylaws.html
> >
> > Some reasons I'd give in favor of the veto model:
> >
> > * Consensus on decisions around new committers/PMC members is pretty
> > important. A majority vote that overrides concerns of one or more PMC
> > members rather than working through those concerns may not be good for
> > the community.
> >
> > * You can usually re-visit a discussion to vote on a new committer or
> > PMC member, but once they're voted on it's more difficult to undo it. If
> > the no voter(s) are saying "not yet convinced," giving some additional
> > time to work that out may be better for the community than forcing it
> > and later regretting it.
> >
> > Reason *not* to have a veto:
> >
> > * It could be abused, or simply cause harm to a community because one or
> > more PMC members are too conservative about adding new committers.
> > Contributors lose interest and the community stagnates.
> >
> > [Other folks probably have different reasons they'd give in favor of or
> > against vetoes, many of whom have been around much longer than I -- so I
> > hope others will chime in as well.]
> >
> > Generally, I lean towards having a veto. If one member has a real
> > concern, I'd prefer to see it worked through and achieve consensus
> > rather than overriding someone.
> >
> > Best,
> >
> > jzb
> > --
> > Joe Brockmeier
> > jzb@zonker.net <javascript:;>
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> > For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
> >
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>
--
Noah Slater
https://twitter.com/nslater
Re: Committer Voting and Vetos
Posted by Branko Čibej <br...@apache.org>.
On 01.10.2014 05:41, Greg Stein wrote:
> On Tue, Sep 30, 2014 at 10:28 AM, Ted Dunning <te...@gmail.com> wrote:
>
>> On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein <gs...@gmail.com> wrote:
>>
>>> To the concrete question, the Subversion project never calls a strict
>>> [VOTE] for new committers or PMC members. We discuss first, and that sets
>>> the direction. People throw out +1 messages, but that is "sure, make it
>> so"
>>> rather than a true vote. Whenever somebody says "wait a minute", then we
>>> do. We don't have formal rules around this stuff, since a general goal of
>>> consensus is so ingrained into the community.
>>>
>> The nice thing about the vote is that there is a [RESULT] message to link
>> to. What does the Subversion project link to in the account request?
>>
> We don't provide a link. There is no reason for Infrastructure to
> second-guess account requests from Officers or ASF Members, so that link is
> optional. *Should* a question ever arise, then it is easy enough to provide
> background information.
Yup. I see the link field there as being mainly for the benefit of the
Incubator and podlings.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Committer Voting and Vetos
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Sep 30, 2014 at 10:28 AM, Ted Dunning <te...@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein <gs...@gmail.com> wrote:
>
> > To the concrete question, the Subversion project never calls a strict
> > [VOTE] for new committers or PMC members. We discuss first, and that sets
> > the direction. People throw out +1 messages, but that is "sure, make it
> so"
> > rather than a true vote. Whenever somebody says "wait a minute", then we
> > do. We don't have formal rules around this stuff, since a general goal of
> > consensus is so ingrained into the community.
> >
>
> The nice thing about the vote is that there is a [RESULT] message to link
> to. What does the Subversion project link to in the account request?
>
We don't provide a link. There is no reason for Infrastructure to
second-guess account requests from Officers or ASF Members, so that link is
optional. *Should* a question ever arise, then it is easy enough to provide
background information.
Cheers,
-g
Re: Committer Voting and Vetos
Posted by Ted Dunning <te...@gmail.com>.
On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein <gs...@gmail.com> wrote:
> To the concrete question, the Subversion project never calls a strict
> [VOTE] for new committers or PMC members. We discuss first, and that sets
> the direction. People throw out +1 messages, but that is "sure, make it so"
> rather than a true vote. Whenever somebody says "wait a minute", then we
> do. We don't have formal rules around this stuff, since a general goal of
> consensus is so ingrained into the community.
>
The nice thing about the vote is that there is a [RESULT] message to link
to. What does the Subversion project link to in the account request?
Re: Committer Voting and Vetos
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Sep 26, 2014 at 10:21 AM, Noah Slater <ns...@apache.org> wrote:
>...
> Specifically, we (CouchDB) see voting as the failure mode of a
> discussion (a useful one non-the-less), or as a last-step requirement
> to officiate a particular set of project-level decisions (that are
> fully enumerated in the bylaws).
>
I very much agree with this sentiment, as does the Apache Subversion
project. In the project's 14 year history, we have held (maybe) about FOUR
actual votes. EVER. And I'm talking both technical and community-issue
votes. I'm really kind of guessing here. I can recall only two, but there
must have been a few others. If a community cannot reach consensus, and
needs a vote instead, then something is wrong (IMO).
To the concrete question, the Subversion project never calls a strict
[VOTE] for new committers or PMC members. We discuss first, and that sets
the direction. People throw out +1 messages, but that is "sure, make it so"
rather than a true vote. Whenever somebody says "wait a minute", then we
do. We don't have formal rules around this stuff, since a general goal of
consensus is so ingrained into the community.
Cheers,
-g
Re: Committer Voting and Vetos
Posted by Noah Slater <ns...@apache.org>.
As the primary author of the CouchDB bylaws, I will weigh in here.
Agree with Ross on the discussion stuff. We actually codify this
attitude in our bylaws.
http://couchdb.apache.org/bylaws.html#decisions
Specifically, we (CouchDB) see voting as the failure mode of a
discussion (a useful one non-the-less), or as a last-step requirement
to officiate a particular set of project-level decisions (that are
fully enumerated in the bylaws).
Wrt to the approval model of voting in committers...
cf. http://couchdb.apache.org/bylaws.html#approval
We chose lazy 2/3 majority, i.e. requires three binding +1 votes and
twice as many binding +1 votes as binding -1 votes.
Very specifically (and this is spelled out in the bylaws) with the
CouchDB project, we only want a -1 vote to have veto power within the
context of code review on a release branch.
There are historical reasons for this. We found that some members of
our community were casting -1 votes fairly carelessly, and expecting
to be able to halt what the majority of the PMC felt were beneficial
initiatives (including elections).
For us, moving to lazy majority or lazy 2/3 majority for most big
decisions was a way to improve our decision-making ability, allowing
us to actually make changes to the project, whereas before we had been
quite sclerotic.
As Joe correctly hits on, some of this was due to me and others
attempting to make some fairly large changes to the project since
about 2012, when we ran into some major issues.
One of the changes I was driving was the redefinition of what a
committer is. I wanted to lower the barrier to entry. Whereas before
we tended to only elect people who were contributing code, I wanted to
expand that and start electing people who were doing other things,
like documentation, translation, marketing, design, community
management, and so on.
This is just one example. But making these sorts of changes
(essentially things that require cultural shifts) is hard when one
person is able cast a -1 vote and shut down an initiative that
everyone else is behind.
On 26 September 2014 16:46, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> Trying to build on Joes answer below....
>
> Given that the ASF is about consensus the vote for.at should be mostly irrelevant. Nominations should have been thoroughly discussed before the vote is called. The vote should be a formality required by the bylaws to demonstrate consensus.
>
> What I mean is there should never be a veto vote cast. The PMC should have already discussed the reasons why someone has their concerns. Those reasons should either have been supported (and no vote called) or talked through and withdrawn.
>
> An example... An individual was proposed, the PMC discussed. Two people felt it was too early because the individual had bit contributed much code, and thus their code quality could bit be assessed. Everyone recognized the individual was contributing to user support, documentation, design etc. In order to have the objections removed a PMC member offered to mentor the new committee should code contributions prove to be problematic. This approach was agreed, the vote was called and passed.
>
> That individual is now a member of the foundation. Had we bot brought then in at the earliest opportunity they may never have become so invested in the foundation and its projects.
>
> Sometimes it's not possible to reach unanimous consensus. In such situations the community needs to delay the vote (they agree the concerns are appropriate) or they use voting to break the deadlock. How the vote is conducted is covered well by Joe.
>
> Sent from my Windows Phone
> ________________________________
> From: Joe Brockmeier<ma...@zonker.net>
> Sent: 9/26/2014 5:00 AM
> To: general@incubator.apache.org<ma...@incubator.apache.org>
> Subject: Re: Committer Voting and Vetos
>
> On Thu, Sep 25, 2014, at 10:59 PM, Alex Harui wrote:
>> In a past discussion about by-laws, some folks were adamant that voting
>> for new committer and PMC members be consensus votes so a single person
>> can block the adding of a candidate.
>>
>> Do any projects use some form of majority voting for new committers?
>> What are the reasons for allowing vetoes?
>
> Yes, some projects have lazy majority/no veto for committer votes.
> CouchDB for example:
>
> http://couchdb.apache.org/bylaws.html
>
> Some reasons I'd give in favor of the veto model:
>
> * Consensus on decisions around new committers/PMC members is pretty
> important. A majority vote that overrides concerns of one or more PMC
> members rather than working through those concerns may not be good for
> the community.
>
> * You can usually re-visit a discussion to vote on a new committer or
> PMC member, but once they're voted on it's more difficult to undo it. If
> the no voter(s) are saying "not yet convinced," giving some additional
> time to work that out may be better for the community than forcing it
> and later regretting it.
>
> Reason *not* to have a veto:
>
> * It could be abused, or simply cause harm to a community because one or
> more PMC members are too conservative about adding new committers.
> Contributors lose interest and the community stagnates.
>
> [Other folks probably have different reasons they'd give in favor of or
> against vetoes, many of whom have been around much longer than I -- so I
> hope others will chime in as well.]
>
> Generally, I lean towards having a veto. If one member has a real
> concern, I'd prefer to see it worked through and achieve consensus
> rather than overriding someone.
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Noah Slater
https://twitter.com/nslater
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Committer Voting and Vetos
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
Trying to build on Joes answer below....
Given that the ASF is about consensus the vote for.at should be mostly irrelevant. Nominations should have been thoroughly discussed before the vote is called. The vote should be a formality required by the bylaws to demonstrate consensus.
What I mean is there should never be a veto vote cast. The PMC should have already discussed the reasons why someone has their concerns. Those reasons should either have been supported (and no vote called) or talked through and withdrawn.
An example... An individual was proposed, the PMC discussed. Two people felt it was too early because the individual had bit contributed much code, and thus their code quality could bit be assessed. Everyone recognized the individual was contributing to user support, documentation, design etc. In order to have the objections removed a PMC member offered to mentor the new committee should code contributions prove to be problematic. This approach was agreed, the vote was called and passed.
That individual is now a member of the foundation. Had we bot brought then in at the earliest opportunity they may never have become so invested in the foundation and its projects.
Sometimes it's not possible to reach unanimous consensus. In such situations the community needs to delay the vote (they agree the concerns are appropriate) or they use voting to break the deadlock. How the vote is conducted is covered well by Joe.
Sent from my Windows Phone
________________________________
From: Joe Brockmeier<ma...@zonker.net>
Sent: 9/26/2014 5:00 AM
To: general@incubator.apache.org<ma...@incubator.apache.org>
Subject: Re: Committer Voting and Vetos
On Thu, Sep 25, 2014, at 10:59 PM, Alex Harui wrote:
> In a past discussion about by-laws, some folks were adamant that voting
> for new committer and PMC members be consensus votes so a single person
> can block the adding of a candidate.
>
> Do any projects use some form of majority voting for new committers?
> What are the reasons for allowing vetoes?
Yes, some projects have lazy majority/no veto for committer votes.
CouchDB for example:
http://couchdb.apache.org/bylaws.html
Some reasons I'd give in favor of the veto model:
* Consensus on decisions around new committers/PMC members is pretty
important. A majority vote that overrides concerns of one or more PMC
members rather than working through those concerns may not be good for
the community.
* You can usually re-visit a discussion to vote on a new committer or
PMC member, but once they're voted on it's more difficult to undo it. If
the no voter(s) are saying "not yet convinced," giving some additional
time to work that out may be better for the community than forcing it
and later regretting it.
Reason *not* to have a veto:
* It could be abused, or simply cause harm to a community because one or
more PMC members are too conservative about adding new committers.
Contributors lose interest and the community stagnates.
[Other folks probably have different reasons they'd give in favor of or
against vetoes, many of whom have been around much longer than I -- so I
hope others will chime in as well.]
Generally, I lean towards having a veto. If one member has a real
concern, I'd prefer to see it worked through and achieve consensus
rather than overriding someone.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Committer Voting and Vetos
Posted by Joe Brockmeier <jz...@zonker.net>.
On Thu, Sep 25, 2014, at 10:59 PM, Alex Harui wrote:
> In a past discussion about by-laws, some folks were adamant that voting
> for new committer and PMC members be consensus votes so a single person
> can block the adding of a candidate.
>
> Do any projects use some form of majority voting for new committers?
> What are the reasons for allowing vetoes?
Yes, some projects have lazy majority/no veto for committer votes.
CouchDB for example:
http://couchdb.apache.org/bylaws.html
Some reasons I'd give in favor of the veto model:
* Consensus on decisions around new committers/PMC members is pretty
important. A majority vote that overrides concerns of one or more PMC
members rather than working through those concerns may not be good for
the community.
* You can usually re-visit a discussion to vote on a new committer or
PMC member, but once they're voted on it's more difficult to undo it. If
the no voter(s) are saying "not yet convinced," giving some additional
time to work that out may be better for the community than forcing it
and later regretting it.
Reason *not* to have a veto:
* It could be abused, or simply cause harm to a community because one or
more PMC members are too conservative about adding new committers.
Contributors lose interest and the community stagnates.
[Other folks probably have different reasons they'd give in favor of or
against vetoes, many of whom have been around much longer than I -- so I
hope others will chime in as well.]
Generally, I lean towards having a veto. If one member has a real
concern, I'd prefer to see it worked through and achieve consensus
rather than overriding someone.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org