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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
