Open Stack

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)