[openstack-dev] What should openstack-specs review approval rules be ?

James E. Blair corvus at inaugust.com
Thu Feb 12 19:23:52 UTC 2015


Thierry Carrez <thierry at openstack.org> 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.




More information about the OpenStack-dev mailing list