Re: Committer Voting and Vetos
On 01.10.2014 05:41, Greg Stein wrote: On Tue, Sep 30, 2014 at 10:28 AM, Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein gst...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Committer Voting and Vetos
On Tue, Sep 30, 2014 at 3:52 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: ...The HTTP Server project has successfully operated by unanimity... As a side note, I often tell people that IMO the HTTP Server is so modular because people couldn't agree on things - it's much easier to get consensus and sometimes unanimity when the things to agree upon are smaller ;-) -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Committer Voting and Vetos
On Fri, Sep 26, 2014 at 10:21 AM, Noah Slater nsla...@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
On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein gst...@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
On Tue, Sep 30, 2014 at 10:28 AM, Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein gst...@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
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+do...@mail.gmail.com%3E Cheers, Brett On 26 Sep 2014, at 1:59 pm, Alex Harui aha...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Committer Voting and Vetos
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 Brockmeiermailto:j...@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 j...@zonker.net javascript:; Twitter: @jzb http://www.dissociatedpress.net/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; -- Noah Slater https://twitter.com/nslater -- Noah Slater https://twitter.com/nslater
Re: Committer Voting and Vetos
On Mon, Sep 29, 2014 at 8:52 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: The HTTP Server PMC has succeeded in working through these issues without evicting a project member, and continuing to make progress. There is a lot of credit due for this. Of course, there are different stresses on each project. Some projects have large commercial interests at stake. Others have incredibly little directly at stake. The problems in these different groups are often very different. My own limited experience is that people often play together better when there is much at stake, except when there is a perception of a zero sum game. When little is at stake, just about anybody can afford to be an ass. This observation has been attributed to a huge number of people [1]. I like the idea that Samuel Johnson was the originator of the core idea. http://quoteinvestigator.com/2013/08/18/acad-politics/
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 j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Committer Voting and Vetos
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 aha...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Committer Voting and Vetos
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 Brockmeiermailto:j...@zonker.net Sent: 9/26/2014 5:00 AM To: general@incubator.apache.orgmailto:general@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 j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Committer Voting and Vetos
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.gard...@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 Brockmeiermailto:j...@zonker.net Sent: 9/26/2014 5:00 AM To: general@incubator.apache.orgmailto:general@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
Re: Committer Voting and Vetos
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 nsla...@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.gard...@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 Brockmeiermailto:j...@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
Re: Committer Voting and Vetos
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 j...@zonker.net javascript:; Twitter: @jzb http://www.dissociatedpress.net/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; -- Noah Slater https://twitter.com/nslater -- Noah Slater https://twitter.com/nslater
Re: Committer Voting and Vetos
On Thu, Sep 25, 2014 at 11:59 PM, Alex Harui aha...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
