[openstack-dev] What should openstack-specs review approval rules be ?
James E. Blair
corvus at inaugust.com
Fri Feb 13 16:33:48 UTC 2015
Thierry Carrez <thierry at openstack.org> 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
More information about the OpenStack-dev
mailing list