diff --git a/reference/tags/assert_follows-standard-deprecation.rst b/reference/tags/assert_follows-standard-deprecation.rst index f5be9a0a9..2276e3d47 100644 --- a/reference/tags/assert_follows-standard-deprecation.rst +++ b/reference/tags/assert_follows-standard-deprecation.rst @@ -99,11 +99,3 @@ In addition, projects assert that: Note: this tag can currently only be applied to services (type:service deliverables). The tag definition may evolve in the future to include library feature deprecation policy and be applicable to libraries as a result. - - -Tag application process -======================= - -Assertion tags are set by the project team PTL. The Technical Committee may -exceptionally remove the tag if they find that the project doesn't actually -follow the requirements for the assertion. diff --git a/reference/tags/assert_supports-rolling-upgrade.rst b/reference/tags/assert_supports-rolling-upgrade.rst index 3471a806d..6c6950f21 100644 --- a/reference/tags/assert_supports-rolling-upgrade.rst +++ b/reference/tags/assert_supports-rolling-upgrade.rst @@ -58,15 +58,3 @@ Requirements meaningful-to-operators rolling upgrade scenario) and available testing resources. At least one representative arrangement must be tested full-stack in the gate. - -Tag application process -======================= - -Assertion tags are set by the project team PTL or suitable designee -based on meeting the above criteria. The Technical Committee may -exceptionally remove the tag if they find that the project doesn't -actually follow the requirements for the assertion. - -The project asserting this tag should do so when the above -requirements are met for the reference implementation(s) or -configuration(s) officially adopted by that project. diff --git a/reference/tags/assert_supports-upgrade.rst b/reference/tags/assert_supports-upgrade.rst index 2244e4dd9..8957f3e2c 100644 --- a/reference/tags/assert_supports-upgrade.rst +++ b/reference/tags/assert_supports-upgrade.rst @@ -57,11 +57,3 @@ Requirements to validate that cold upgrades from the previous stable release are not broken. Any upgrade tasks that would be documented as above are codified in the testing to demonstrate correctness. - -Tag application process -======================= - -Assertion tags are set by the project team PTL or suitable designee -based on meeting the above criteria. The Technical Committee may -exceptionally remove the tag if they find that the project doesn't -actually follow the requirements for the assertion. diff --git a/reference/tags/assert_supports-zero-downtime-upgrade.rst b/reference/tags/assert_supports-zero-downtime-upgrade.rst index 4ca25c413..8e773a19d 100644 --- a/reference/tags/assert_supports-zero-downtime-upgrade.rst +++ b/reference/tags/assert_supports-zero-downtime-upgrade.rst @@ -65,15 +65,3 @@ Requirements regression by implementing a zero-downtime gate job wherein both a new version of the service and an old version of the service are run concurrently. - -Tag application process -======================= - -Assertion tags are set by the project team PTL or suitable designee based on -meeting the above criteria. The Technical Committee may exceptionally remove -the tag if they find that the project doesn't actually follow the requirements -for the assertion. - -The project asserting this tag should do so when the above requirements are met -for the reference implementation(s) or configuration(s) officially adopted by -that project. diff --git a/reference/tags/assert_supports-zero-impact-upgrade.rst b/reference/tags/assert_supports-zero-impact-upgrade.rst index 0233b24e5..54e103cdb 100644 --- a/reference/tags/assert_supports-zero-impact-upgrade.rst +++ b/reference/tags/assert_supports-zero-impact-upgrade.rst @@ -62,15 +62,3 @@ Requirements are run concurrently under load. *A measurement of API response times must show that there are no statistically significant outliers during the upgrade process when compared to normal operations.* - -Tag application process -======================= - -Assertion tags are set by the project team PTL or suitable designee based on -meeting the above criteria. The Technical Committee may exceptionally remove -the tag if they find that the project doesn't actually follow the requirements -for the assertion. - -The project asserting this tag should do so when the above requirements are met -for the reference implementation(s) or configuration(s) officially adopted by -that project. diff --git a/reference/tags/index.rst b/reference/tags/index.rst index 37062f18c..f10c99244 100644 --- a/reference/tags/index.rst +++ b/reference/tags/index.rst @@ -2,6 +2,19 @@ Tags ====== +Tag application processes +========================= + +Unless a specific tag, or group of tags, states otherwise, the criteria +required for each tag is objective and anyone may propose adding or removing +tags to a set of projects by proposing a change to the ``openstack/governance`` +repository. The change is reviewed by the Technical Committee and approved +using standard resolution approval rules, including discussion during at least +one Technical Committee public IRC meeting. + +The Technical Committee may approve any future updates to tag definitions and +otherwise defer applications of tags. + TC Managed Tags =============== @@ -27,8 +40,18 @@ Team Description Tags team_diverse-affiliation team_single-vendor -Project Assertions Tags -======================= +Project Assertion Tags +====================== + +Project assertion tags are set by the project team PTL or suitable designee +based on meeting the documented criteria. + +The project asserting these tags should do so when the documented requirements +are met for the reference implementation(s) or configuration(s) officially +adopted by that project. + +The Technical Committee may exceptionally remove tags if they find that the +project doesn't actually meet the documented criteria. .. toctree:: :maxdepth: 1 diff --git a/reference/tags/stable_follows-policy.rst b/reference/tags/stable_follows-policy.rst index 0a696ebfe..4dab82ed0 100644 --- a/reference/tags/stable_follows-policy.rst +++ b/reference/tags/stable_follows-policy.rst @@ -53,10 +53,9 @@ stable branches. Tag application process ======================= -Anyone may propose adding or removing this tag to a set of deliverables by -proposing a change to the openstack/governance repository. The change is -reviewed by the `Stable Branch Maintenance team`_, and the Technical Committee -finally approves it using its lazy consensus approval rule. +Proposals to add or remove this tag must be reviewed by the +`Stable Branch Maintenance team`_ prior to final approval by +the Technical Committee. Deprecation diff --git a/reference/tags/starter-kit_compute.rst b/reference/tags/starter-kit_compute.rst index 659dd4f24..f13f094b5 100644 --- a/reference/tags/starter-kit_compute.rst +++ b/reference/tags/starter-kit_compute.rst @@ -201,10 +201,7 @@ Requirements Tag application process ======================= -The TC is responsible for maintaining the tags in the 'starter kit' category. - -There is no need to apply for addition/removal. Changes externally proposed -will be reviewed and approved by the TC. +There is no need to apply for addition or removal. Deprecation =========== diff --git a/reference/tags/tc_approved-release.rst b/reference/tags/tc_approved-release.rst index 94fa61663..bc53195a7 100644 --- a/reference/tags/tc_approved-release.rst +++ b/reference/tags/tc_approved-release.rst @@ -74,16 +74,10 @@ the Board (as well as working groups like the Interop committee) to best understand the demand for the commercial trademark by OpenStack users and vendors. -As such, changes to this tag are expected to come from the Interop -working group based on their judgment that the marketplace has evolved -and a new set of projects should be used in future versions of -trademark programs. They should propose adding or removing this tag to -a project by proposing a change to the openstack/governance -repository. The change is reviewed by the Technical Committee and -approved using standard resolution approval rules, including -discussion at at least one Technical Committee public IRC meeting. - - +As such, changes proposing to add or remove this tag are expected to +come from the Interop working group based on their judgment that the +marketplace has evolved and a new set of projects should be used in +future versions of trademark programs. Deprecation =========== diff --git a/reference/tags/team_diverse-affiliation.rst b/reference/tags/team_diverse-affiliation.rst index 126244069..7de473bd0 100644 --- a/reference/tags/team_diverse-affiliation.rst +++ b/reference/tags/team_diverse-affiliation.rst @@ -69,20 +69,6 @@ Based on how requirements are defined, this tag is only applicable for projects where their primary deliverables are represented by commits and reviews in git. An example of where this doesn't make sense is the release management team. -Tag application process -======================= - -The criteria for this tag is very objective. The TC could approve any future -updates to the tag definition and otherwise defer application of the tag. A -method for delegating this is TBD, so in the meantime, we default back to the -following process: - -Anyone may propose adding or removing this tag to a set of projects by -proposing a change to the openstack/governance repository. The change is -reviewed by the Technical Committee and approved using standard resolution -approval rules, including discussion at at least one Technical Committee -public IRC meeting. - Deprecation =========== diff --git a/reference/tags/team_single-vendor.rst b/reference/tags/team_single-vendor.rst index e50a70f8a..4bae8233f 100644 --- a/reference/tags/team_single-vendor.rst +++ b/reference/tags/team_single-vendor.rst @@ -71,21 +71,6 @@ Based on how requirements are defined, this tag is only applicable for projects where their primary deliverables are represented by commits and reviews in git. -Tag application process -======================= - -The criteria for this tag is objective. The TC could approve any future -updates to the tag definition and otherwise defer application of the tag. A -method for delegating this is TBD, so in the meantime, we default back to the -following process: - -Anyone may propose adding or removing this tag to a set of projects by -proposing a change to the openstack/governance repository. The change is -reviewed by the Technical Committee and approved using standard resolution -approval rules, including discussion at at least one Technical Committee -public IRC meeting. - - Deprecation =========== diff --git a/reference/tags/vulnerability_managed.rst b/reference/tags/vulnerability_managed.rst index aac4377fa..35cb7bf79 100644 --- a/reference/tags/vulnerability_managed.rst +++ b/reference/tags/vulnerability_managed.rst @@ -122,13 +122,8 @@ Requirements Tag application process ======================= -Anyone may propose adding or removing this tag to a set of -deliverables by proposing a change to the openstack/governance -repository. The change is reviewed by the VMT and Technical -Committee and approved using standard resolution approval rules, -including discussion at at least one Technical Committee public IRC -meeting. - +Proposals to add or remove this tag must be reviewed by the VMT +prior to final approval by the Technical Committee. Deprecation ===========