Thierry Carrez <[email protected]> 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, "TC votes". To address this requirement: * Non-TC members may register their approval or disapproval with a vote (they currently may only leave comments to that effect). We could do what we are currently doing in the cross-project repo and allow everyone to vote in the Code-Review column and let TC members vote +2/-2. Because in the governance repo we must be able to count dissenting TC member votes without treating them as vetos, we would set the Code-Review label function to "NoBlock" or "MaxNoBlock" and let the TC chair tally the +2 and -2 votes. Alternatively, we could create a separate review category for community votes (using "NoBlock") and allow anyone to +1/-1 and then additionally have a category for TC +1/-1 (using "NoBlock" or "MaxNoBlock"). In this scenario, we could also write prolog rules to require 7 +1 votes. To address this potential requirement (in the cross-project repo only): * TC members may veto with a -2 Code-Review vote. (This requirement has not achieved consensus.) If we chose to allow TC member veto of cross-project specs, then whatever category the TC members vote in would use "AnyWithBlock" or "MaxWithBlock". If TC and community share a category, we could add a -3 so that -2 means TC dissent, and -3 means TC veto. If they use two different categories, we can use -1 in the TC category to mean dissent and -2 to mean veto. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
