document the topic tags for each house rule

Add the gerrit topic tag to use when applying each house rule to a patch.

Change-Id: Ia8c2ae26fc7e60f7bc3f03fb4898cf91de36773d
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This commit is contained in:
Doug Hellmann 2018-12-13 08:55:33 -05:00
parent c7eca6b5fb
commit 91ad4083ea
2 changed files with 18 additions and 0 deletions

View File

@ -119,6 +119,8 @@ committee that means a minimum of 5 approvers). After a motion receives
sufficient votes to pass, it must stay open for further comments and voting for
a minimum of 3 calendar days.
Patches with motions should use the gerrit topic tag ``formal-vote``.
Election for PTL seats
======================
@ -241,3 +243,6 @@ Amendments to this Technical Committee charter shall be proposed in a special
motion, which needs to be approved by the affirmative vote of at least
two-thirds of the total number of TC members (rounded up: in a 13-member
committee that means a minimum of 9 approvers).
Patches with charter amendments should use the gerrit topic tag
``charter-change``.

View File

@ -11,6 +11,8 @@ document lists those "house rules" for reference.
Typo fixes
----------
:Gerrit topic: ``typo-fix``
When the change fixes content that is obviously wrong (updates a PTL email
address, fixes a typo...) then the chair is allowed to directly approve them.
Typo fixes proposed by the chair should have 2 RollCall+1 votes from TC members.
@ -18,6 +20,8 @@ Typo fixes proposed by the chair should have 2 RollCall+1 votes from TC members.
Code changes
------------
:Gerrit topic: ``code-change``
The `openstack/governance` repository also contains code to build and publish
pages on the governance.openstack.org website. For those we apply the normal
code review rules (with RollCall votes being considered +-2): change will be
@ -27,6 +31,9 @@ approved once 2 `RollCall+1` (other than the change owner) are posted (and no
Delegated tags
--------------
:Gerrit topic: the name of the tag being applied (``stable:follows-policy``,
``vulnerability:managed``)
Some tags are delegated to a specific team, like
:ref:`tag-stable:follows-policy`
or :ref:`tag-vulnerability:managed`. Those need to get approved by the
@ -36,6 +43,8 @@ approval is given.
Delegated metadata
------------------
:Gerrit topic: ``release-management``
The ``release-management`` setting for a deliverable is delegated to
the PTL of the Release Management team. When proposed or approved by
the PTL, changes can be directly approved by the chair.
@ -43,6 +52,8 @@ the PTL, changes can be directly approved by the chair.
Other project team updates
--------------------------
:Gerrit topic: ``project-update``
For other changes within an existing project team, like addition of a new git
repository or self-assertion of a tag, we use lazy consensus. If there is no
objection posted one week after the change is proposed (or a significant new
@ -60,6 +71,8 @@ change, but should report on that exception in the TC update.
Goal Updates from PTLs
----------------------
:Gerrit topic: ``goal-update``
PTLs will acknowledge community-wide goals at the start of each cycle
by providing links to artifacts for tracking the work, or an
explanation of why work is not going to be done. They will also