Merge "document the topic tags for each house rule"
This commit is contained in:
commit
c4c352a652
|
@ -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``.
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue