[openstack-dev] [kolla] our 3 voting processes in detail

Steven Dake (stdake) stdake at cisco.com
Sat Jun 18 01:30:35 UTC 2016

Hey core reviewers,

I was speaking with one of the core reviewers of Kolla today who said "only you can nominate people for core reviewer".  By you, he meant me :)  This is absolutely not true and I'd like to set the record straight on our three voting processes we have developed over the last 3 years of the project's existence:

For core reviewer nominations:
If you have someone in mind you would like to propose, please contact the PTL via email or irc or cellphone or carrier pigeon.  Feel free to make a short writeup about the individual's accomplishments or if you don't the PTL will.  I will send it on or craft a message for the mailing list.  The core reviewer nominations while originating from my email address represent a nomination from the community, not me personally.

Requires majority of core reviewers to vote +1 with no veto vote within 1 week window.  Voting closes early on unanimous vote or veto.

For policy matters:
If you want to trigger a policy change, please either send an email to the mailing list with the [kolla][vote] tag with your proposal or contact the PTL to execute the vote.

Requires majority of core reviewers to vote +1 within 1 week window.  No veto is permitted.  Voting closes early when majority is reached.

For technical specifications of a contentious nature or that are highly complex changes:
Kolla uses specifications as a last resort mechanism when other forms of communication have failed.  Another use of specifications is to discuss highly complex topics that touch a whole lot of Kolla.  Many times after the specification is created and discussed in gerrit, it is abandoned as the review process itself sets a direction that breaks the logjam.

Anyone may submit a specification for review.

Requires majority of core reviewers to vote +2.  There is no time window.  The final majority vote may workflow the specification.  No veto (A vote of -2)  is permitted.

NB: The reason no veto is permitted on specs or policy matters is to break logjams.  Democracies operate best when there are no veto abilities.  This prevents dictatorships.
NB: The reason veto is permitted on core review nominations is related to how OpenStack operates and has a whole lot to do with trust.
NB: If the PTL is unresponsive (Ill, on vacation for 3 months in the bahamas, whatever) please feel free to take it upon yourself to execute the actions declared above that the PTL would typically do.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160618/a6c4dc27/attachment.html>

More information about the OpenStack-dev mailing list