Generalize tag application processes

Prior to this change, each tag had it's own specific tag application
process, sometimes with zero (or just inconsequential) changes in
wording when compared to a similar tag.

In order to eliminate these redundancies, this patch proposes to
generalize the tag application process on the main tags page, and allow
each tag, or group of tags, to further specify additional process
requirements (such as requiring prior approval by a group other than the
TC, or identifying the group expected to submit tag applications).

This should also make it easier to review new tags in the future.

Change-Id: I7d78dcc95ed51794c2456c827187a7087126dd21

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.

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.

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.

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.

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.

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

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

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
 ===========

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
 ===========

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
 ===========

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
 ===========
 

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
 ===========