Re: [openstack-dev] What should openstack-specs review approval rules be ?
On Fri, Feb 13, 2015, at 11:33 AM, James E. Blair wrote: > Thierry Carrez writes: > > >> Current Cross-Project Repo Rules > >> > ... > >> * Only the TC chair may vote Workflow +1. > > > > My understanding is that currently, any TC member can Workflow+1 (which > > lead to the accidental approval of the previous spec). > > I think that was instachanged by Doug after the TC meeting: > > https://review.openstack.org/#/c/150581/ > > So the immediate problem is abated, and we can deliberate about any > other changes. > > >> Additionally, we could write a custom submit rule that requires at > >> least 7 +1 votes in order for the change to be submittable. > > > > Our voting rules are slightly more complex than that, as you can see here: > > > > http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n77 > > > > The rule actually is "more positive votes than negative votes, and a > > minimum of 5 positive votes". The "7 YES" rule is just a shortcut: once > > we reach it, we can safely approve (otherwise we basically have to wait > > for "all votes to be cast", which with asynchronous voting, and the > > difficulty to distinguish +0 from "not voted yet", is not so easy to > > achieve). > > > > So unless you can encode that in a rule, I'd keep it under the > > responsibility of the chair to properly (and publicly) tally the votes > > (which I do in the +2 final comment) according to our charter rules. > > The mechanism for such a change is Prolog. I suspect that encoding that > rule is possible, though I am not familiar enough with Prolog to say for > sure. The part of me that loves learning new programming languages > wants to find out. But part of me agrees with you and thinks we should > just leave it to the Chair. > > Actually, I think I may have missed a requirement that would preclude > the use of that rule. We may consider "Chair is able to approve trivial > administrative changes to the governance repo without a full vote" as a > requirement, in which case we want the status quo. Yes, indeed. We also recently agreed to let the Chair rebase changes that were approved but can't be merged to avoid needing another vote just because git is confused. Doug > > -Jim > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What should openstack-specs review approval rules be ?
Thierry Carrez writes: >> Current Cross-Project Repo Rules >> ... >> * Only the TC chair may vote Workflow +1. > > My understanding is that currently, any TC member can Workflow+1 (which > lead to the accidental approval of the previous spec). I think that was instachanged by Doug after the TC meeting: https://review.openstack.org/#/c/150581/ So the immediate problem is abated, and we can deliberate about any other changes. >> Additionally, we could write a custom submit rule that requires at >> least 7 +1 votes in order for the change to be submittable. > > Our voting rules are slightly more complex than that, as you can see here: > > http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n77 > > The rule actually is "more positive votes than negative votes, and a > minimum of 5 positive votes". The "7 YES" rule is just a shortcut: once > we reach it, we can safely approve (otherwise we basically have to wait > for "all votes to be cast", which with asynchronous voting, and the > difficulty to distinguish +0 from "not voted yet", is not so easy to > achieve). > > So unless you can encode that in a rule, I'd keep it under the > responsibility of the chair to properly (and publicly) tally the votes > (which I do in the +2 final comment) according to our charter rules. The mechanism for such a change is Prolog. I suspect that encoding that rule is possible, though I am not familiar enough with Prolog to say for sure. The part of me that loves learning new programming languages wants to find out. But part of me agrees with you and thinks we should just leave it to the Chair. Actually, I think I may have missed a requirement that would preclude the use of that rule. We may consider "Chair is able to approve trivial administrative changes to the governance repo without a full vote" as a requirement, in which case we want the status quo. -Jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What should openstack-specs review approval rules be ?
James E. Blair wrote: > [...] > I think in general though, it boils down to the fact that we need to > answer these questions for each of the repos: > > A) Should the broader community register ±1 or simply comments? (Now >that we may distinguish them from TC member votes.) > B) Should individual TC members get a veto? > > I personally think the answer to A is "votes" and B is "no" in both > cases. I'm also okay with sticking with "comments" for the governance > repo. I fell pretty strongly about not having veto. I'd answer the same. Votes and no veto. > [...] > == > > Since upgrading to Gerrit 2.8, we have some additional tools at our > disposal for configuring voting categories. For some unique > repositories such as governance and cross-project specs, we may want > to reconfigure voting there. > > Governance Repo Requirements > > > I believe that the following are requirements for the Governance > repository: > > * TC members can express approval or disapproval in a way that > identifies their vote as a vote of a member of the TC. > * TC members may not veto. > * Anyone should be able to express their opinion. > * Only the TC chair may approve the change. This is so that the chair > is responsible for the procedural aspects of the vote (ie, when it > is finalized). > > Current Governance Repo Rules > - > > These are currently satisfied by the following rules in Gerrit: > > * Anyone may comment on a change without leaving a vote. > * Only TC members may vote +1/-1 in Code-Review. > * Only the TC chair may vote Code-Review +2 and Workflow +1. > > Unsatisfied Governance Repo Requirements > > > This does not satisfy the following potential requirements: > > * The TC chair may vote -1 and still approve a disputed change with 7 > yes votes (the chair currently would need to leave a comment > indicating the actual vote tally). > * Non-TC members may register their approval or disapproval with a > vote (they currently may only leave comments to that effect). Agreed. > Cross-Project Repo Requirements > --- > > * TC members can express approval or disapproval in a way that > identifies their vote as a vote of a member of the TC. > * TC members may not veto. (This requirement has not achieved > consensus.) > * Non-TC members may register their approval or disapproval with a > vote (we must be able to easily see that PTLs of affected projects > have weighed in). > * Only the TC chair may approve the change. This is so that the chair > is responsible for the procedural aspects of the vote (ie, when it > is finalized). > > Current Cross-Project Repo Rules > > > These are currently satisfied by the following rules in Gerrit: > > * Anyone may comment on a change and leave a vote. > * Only TC members may vote +2 in Code-Review. > * Only the TC chair may vote Workflow +1. My understanding is that currently, any TC member can Workflow+1 (which lead to the accidental approval of the previous spec). > Unsatisfied Governance Repo Requirements > > The following potential requirements are not satisfied: > > * TC members may veto with a -2 Code-Review vote. (This requirement > has not achieved consensus.) > > Potential Changes > = > > To address the unsatisfied requirements, we could make the following > changes, which would only apply to the repos in question: > > To address this requirement: > * The TC chair may vote -1 and still approve a disputed change with 7 > yes votes (the chair currently would need to leave a comment > indicating the actual vote tally). > > We could change the Code-Review label function from "MaxWithBlock" to > "NoBlock", so that the votes in Code-Review are ignored by Gerrit, and > only enforced by the chair. > > Additionally, we could write a custom submit rule that requires at > least 7 +1 votes in order for the change to be submittable. Our voting rules are slightly more complex than that, as you can see here: http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n77 The rule actually is "more positive votes than negative votes, and a minimum of 5 positive votes". The "7 YES" rule is just a shortcut: once we reach it, we can safely approve (otherwise we basically have to wait for "all votes to be cast", which with asynchronous voting, and the difficulty to distinguish +0 from "not voted yet", is not so easy to achieve). So unless you can encode that in a rule, I'd keep it under the responsibility of the chair to properly (and publicly) tally the votes (which I do in the +2 final comment) according to our charter rules. -- Thierry Carrez (ttx) __ Open
Re: [openstack-dev] What should openstack-specs review approval rules be ?
On 28/01/15 14:25 +0100, Thierry Carrez wrote: Hi everyone, When we first introduced the cross-project specs (specs for things that may potentially affect all OpenStack projects, or where more convergence is desirable), we defaulted to rather simple rules for approval: - discuss the spec in a cross-project meeting - let everyone +1/-1 and seek consensus I don't mind having the TC leading the direction of cross-project specs. However, I think giving +1/-1 to the rest of the community has some extra value. Besides being able to express opinion easily, it makes it clear at a first glance what the general feeling about a spec is. Furthermore, in very active reviews, there's a chance that some comments could be, unintentionally, skipped due to the activity on the spec. Having an explicit, but not definitive, vote for the community is important and also inclusive. Flavio - wait for the affected PTLs to vote - wait even more - tally the votes (and agree a consensus is reached) during a TC meeting - give +2/Worflow+1 to all TC members to let them push the Go button However, the recent approval of the Log guidelines (https://review.openstack.org/#/c/132552/) revealed that those may not be the rules we are looking for. Sean suggested that only the TC chair should be able to workflow+1 to avoid accidental approval. Doug suggested that we should use the TC voting rules (7 YES, or at least 5 YES and more YES than NO) on those. In yesterday's meeting, Sean suggested that TC members should still have a -2-like veto (if there is no TC consensus on the fact that community consensus is reached, there probably is no real consensus). There was little time to discuss this more in yesterday's TC meeting, so I took the action to push that discussion to the ML. So what is it we actually want for that repository ? In a world where Gerrit can do anything, what would you like to have ? Personally, I want our technical community in general, and our PTLs/CPLs in particular, to be able to record their opinion on the proposed cross-project spec. Then, if consensus is reached, the spec should be approved. This /could/ be implemented in Gerrit by giving +1/-1 to everyone to express technical opinion and +2/-2 to TC members to evaluate consensus (with Workflow+1 to the TC chair to mark when all votes are collected and consensus is indeed reached). Other personal opinions on how you'd like this repository reviews to be run ? -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco pgpMnOREag89a.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What should openstack-specs review approval rules be ?
On Wed, Jan 28, 2015, at 08:25 AM, Thierry Carrez wrote: > Hi everyone, > > When we first introduced the cross-project specs (specs for things that > may potentially affect all OpenStack projects, or where more convergence > is desirable), we defaulted to rather simple rules for approval: > > - discuss the spec in a cross-project meeting > - let everyone +1/-1 and seek consensus > - wait for the affected PTLs to vote > - wait even more > - tally the votes (and agree a consensus is reached) during a TC meeting > - give +2/Worflow+1 to all TC members to let them push the Go button > > However, the recent approval of the Log guidelines > (https://review.openstack.org/#/c/132552/) revealed that those may not > be the rules we are looking for. > > Sean suggested that only the TC chair should be able to workflow+1 to > avoid accidental approval. > > Doug suggested that we should use the TC voting rules (7 YES, or at > least 5 YES and more YES than NO) on those. > > In yesterday's meeting, Sean suggested that TC members should still have > a -2-like veto (if there is no TC consensus on the fact that community > consensus is reached, there probably is no real consensus). In the past we've shown -1 votes to be a sign of a lack of consensus, and I'm not aware of any cases where a close vote went through. In fact, the only close vote I can remember since we started voting in gerrit was the Zaqar graduation vote, and that outcome kept the status quo in the face of no clear consensus. Given that, I'm not sure we need a true veto but I could accept it if that's the consensus. > > There was little time to discuss this more in yesterday's TC meeting, so > I took the action to push that discussion to the ML. > > So what is it we actually want for that repository ? In a world where > Gerrit can do anything, what would you like to have ? > > Personally, I want our technical community in general, and our PTLs/CPLs > in particular, to be able to record their opinion on the proposed > cross-project spec. Then, if consensus is reached, the spec should be > approved. > > This /could/ be implemented in Gerrit by giving +1/-1 to everyone to > express technical opinion and +2/-2 to TC members to evaluate consensus > (with Workflow+1 to the TC chair to mark when all votes are collected > and consensus is indeed reached). > > Other personal opinions on how you'd like this repository reviews to be > run ? > > -- > Thierry Carrez (ttx) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What should openstack-specs review approval rules be ?
Thierry Carrez writes: > So what is it we actually want for that repository ? In a world where > Gerrit can do anything, what would you like to have ? > > Personally, I want our technical community in general, and our PTLs/CPLs > in particular, to be able to record their opinion on the proposed > cross-project spec. Then, if consensus is reached, the spec should be > approved. > > This /could/ be implemented in Gerrit by giving +1/-1 to everyone to > express technical opinion and +2/-2 to TC members to evaluate consensus > (with Workflow+1 to the TC chair to mark when all votes are collected > and consensus is indeed reached). Thanks for starting this. Despite the fact that I was explicitly looking for this thread, I still missed it. I think in general though, it boils down to the fact that we need to answer these questions for each of the repos: A) Should the broader community register +/-1 or simply comments? (Now that we may distinguish them from TC member votes.) B) Should individual TC members get a veto? I personally think the answer to A is "votes" and B is "no" in both cases. I'm also okay with sticking with "comments" for the governance repo. I fell pretty strongly about not having veto. Below I am including a whole bunch of text which is both my analysis of all of the requirements and potential requirements, the current state, and technical implementations of changes we might want. Sorry it's so long and complicated, but the gist is that we do have options, and if we can agree on the above 2 questions, I think the next steps are fairly obvious. -Jim == Since upgrading to Gerrit 2.8, we have some additional tools at our disposal for configuring voting categories. For some unique repositories such as governance and cross-project specs, we may want to reconfigure voting there. Governance Repo Requirements I believe that the following are requirements for the Governance repository: * TC members can express approval or disapproval in a way that identifies their vote as a vote of a member of the TC. * TC members may not veto. * Anyone should be able to express their opinion. * Only the TC chair may approve the change. This is so that the chair is responsible for the procedural aspects of the vote (ie, when it is finalized). Current Governance Repo Rules - These are currently satisfied by the following rules in Gerrit: * Anyone may comment on a change without leaving a vote. * Only TC members may vote +1/-1 in Code-Review. * Only the TC chair may vote Code-Review +2 and Workflow +1. Unsatisfied Governance Repo Requirements This does not satisfy the following potential requirements: * The TC chair may vote -1 and still approve a disputed change with 7 yes votes (the chair currently would need to leave a comment indicating the actual vote tally). * Non-TC members may register their approval or disapproval with a vote (they currently may only leave comments to that effect). Cross-Project Repo Requirements --- * TC members can express approval or disapproval in a way that identifies their vote as a vote of a member of the TC. * TC members may not veto. (This requirement has not achieved consensus.) * Non-TC members may register their approval or disapproval with a vote (we must be able to easily see that PTLs of affected projects have weighed in). * Only the TC chair may approve the change. This is so that the chair is responsible for the procedural aspects of the vote (ie, when it is finalized). Current Cross-Project Repo Rules These are currently satisfied by the following rules in Gerrit: * Anyone may comment on a change and leave a vote. * Only TC members may vote +2 in Code-Review. * Only the TC chair may vote Workflow +1. Unsatisfied Governance Repo Requirements The following potential requirements are not satisfied: * TC members may veto with a -2 Code-Review vote. (This requirement has not achieved consensus.) Potential Changes = To address the unsatisfied requirements, we could make the following changes, which would only apply to the repos in question: To address this requirement: * The TC chair may vote -1 and still approve a disputed change with 7 yes votes (the chair currently would need to leave a comment indicating the actual vote tally). We could change the Code-Review label function from "MaxWithBlock" to "NoBlock", so that the votes in Code-Review are ignored by Gerrit, and only enforced by the chair. Additionally, we could write a custom submit rule that requires at least 7 +1 votes in order for the change to be submittable. Additionally, we could change the name of the review category from "Code-Review" to something else, for instance,
Re: [openstack-dev] What should openstack-specs review approval rules be ?
I am of the opinion that the +1/-1 from non tc members can be valuable, but similarly it would be easy to get just comments. The TC is the body I expect to help determine the direction of cross project initiatives such as the logging guidelines. As a PTL I feel confident the TC is the right body to do the voting and the same rules as the governance repo (with chair +1 workflow) seems to be a great idea. Communicating the topics via the ML and the cross project meeting should help to get the PTLs and CPLs involved in the process, which is highly important. The ML can help to bring in other views. I would rather trust the TC (who has not shown any reason to question their ability to determine community consensus) to help make sure we don't stall on these specs than have endless waiting. I like the proposal to use the TC voting rules. --Morgan On Wednesday, January 28, 2015, Thierry Carrez wrote: > Hi everyone, > > When we first introduced the cross-project specs (specs for things that > may potentially affect all OpenStack projects, or where more convergence > is desirable), we defaulted to rather simple rules for approval: > > - discuss the spec in a cross-project meeting > - let everyone +1/-1 and seek consensus > - wait for the affected PTLs to vote > - wait even more > - tally the votes (and agree a consensus is reached) during a TC meeting > - give +2/Worflow+1 to all TC members to let them push the Go button > > However, the recent approval of the Log guidelines > (https://review.openstack.org/#/c/132552/) revealed that those may not > be the rules we are looking for. > > Sean suggested that only the TC chair should be able to workflow+1 to > avoid accidental approval. > > Doug suggested that we should use the TC voting rules (7 YES, or at > least 5 YES and more YES than NO) on those. > > In yesterday's meeting, Sean suggested that TC members should still have > a -2-like veto (if there is no TC consensus on the fact that community > consensus is reached, there probably is no real consensus). > > There was little time to discuss this more in yesterday's TC meeting, so > I took the action to push that discussion to the ML. > > So what is it we actually want for that repository ? In a world where > Gerrit can do anything, what would you like to have ? > > Personally, I want our technical community in general, and our PTLs/CPLs > in particular, to be able to record their opinion on the proposed > cross-project spec. Then, if consensus is reached, the spec should be > approved. > > This /could/ be implemented in Gerrit by giving +1/-1 to everyone to > express technical opinion and +2/-2 to TC members to evaluate consensus > (with Workflow+1 to the TC chair to mark when all votes are collected > and consensus is indeed reached). > > Other personal opinions on how you'd like this repository reviews to be > run ? > > -- > Thierry Carrez (ttx) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
