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:
@@ -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
|
sufficient votes to pass, it must stay open for further comments and voting for
|
||||||
a minimum of 3 calendar days.
|
a minimum of 3 calendar days.
|
||||||
|
|
||||||
|
Patches with motions should use the gerrit topic tag ``formal-vote``.
|
||||||
|
|
||||||
Election for PTL seats
|
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
|
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
|
two-thirds of the total number of TC members (rounded up: in a 13-member
|
||||||
committee that means a minimum of 9 approvers).
|
committee that means a minimum of 9 approvers).
|
||||||
|
|
||||||
|
Patches with charter amendments should use the gerrit topic tag
|
||||||
|
``charter-change``.
|
||||||
|
|||||||
@@ -11,6 +11,8 @@ document lists those "house rules" for reference.
|
|||||||
Typo fixes
|
Typo fixes
|
||||||
----------
|
----------
|
||||||
|
|
||||||
|
:Gerrit topic: ``typo-fix``
|
||||||
|
|
||||||
When the change fixes content that is obviously wrong (updates a PTL email
|
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.
|
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.
|
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
|
Code changes
|
||||||
------------
|
------------
|
||||||
|
|
||||||
|
:Gerrit topic: ``code-change``
|
||||||
|
|
||||||
The `openstack/governance` repository also contains code to build and publish
|
The `openstack/governance` repository also contains code to build and publish
|
||||||
pages on the governance.openstack.org website. For those we apply the normal
|
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
|
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
|
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
|
Some tags are delegated to a specific team, like
|
||||||
:ref:`tag-stable:follows-policy`
|
:ref:`tag-stable:follows-policy`
|
||||||
or :ref:`tag-vulnerability:managed`. Those need to get approved by the
|
or :ref:`tag-vulnerability:managed`. Those need to get approved by the
|
||||||
@@ -36,6 +43,8 @@ approval is given.
|
|||||||
Delegated metadata
|
Delegated metadata
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
|
:Gerrit topic: ``release-management``
|
||||||
|
|
||||||
The ``release-management`` setting for a deliverable is delegated to
|
The ``release-management`` setting for a deliverable is delegated to
|
||||||
the PTL of the Release Management team. When proposed or approved by
|
the PTL of the Release Management team. When proposed or approved by
|
||||||
the PTL, changes can be directly approved by the chair.
|
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
|
Other project team updates
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
||||||
|
:Gerrit topic: ``project-update``
|
||||||
|
|
||||||
For other changes within an existing project team, like addition of a new git
|
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
|
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
|
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
|
Goal Updates from PTLs
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
|
:Gerrit topic: ``goal-update``
|
||||||
|
|
||||||
PTLs will acknowledge community-wide goals at the start of each cycle
|
PTLs will acknowledge community-wide goals at the start of each cycle
|
||||||
by providing links to artifacts for tracking the work, or an
|
by providing links to artifacts for tracking the work, or an
|
||||||
explanation of why work is not going to be done. They will also
|
explanation of why work is not going to be done. They will also
|
||||||
|
|||||||
Reference in New Issue
Block a user