No longer support attributes in tags

This postulates that tags should be tags, and therefore shouldn't
have attributes.

Attributes in tags were originally meant to hold additional
information on the area described by the tag. However, ideally
tags are self-contained units of information, with an opinionated
description (and ideally an objective set of application rules).
Keeping the option of having attributes in tags adds useless format
complexity and steers tags in the direction of structured project
metadata. Project structured metadata (like the ops-data) is fine,
it's just not the same thing as tags. Continuing to support
attributes in tags IMHO encourages the confusion between the two.

The integrated-release tag was the only one using attributes,
and it's now removed.

Change-Id: I1dd5c8090405bd87e8947892d78c62509258e363

reference/tag-template.rst

@@ -85,16 +85,3 @@ Deprecation
 Some tags may have a deprecation period (where a project retains the tag but
 only until a certain announced date). If the proposed tag has a deprecation
 period, its duration (and any other specific rules) should be listed here.
-
-
-Attributes
-==========
-
-Tags may have attributes which provide extra information. Those attributes
-(and their values) should be described in this section.
-
-example-attribute
------------------
-
-Description of the example-attribute tag attribute, and of the values it may
-take.

reference/tags/compute_starter_kit.rst

@@ -214,12 +214,6 @@ concept will be revisited at every major release boundary for
 suitability.
 
 
-Attributes
-==========
-
-No attributes
-
-
 References
 ==========
 [1] - http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up

reference/tags/release_cycle-with-intermediary.rst

@@ -68,9 +68,3 @@ they match the current release model followed by each code repository.
 There is no need to apply for addition/removal. Changes externally proposed
 will be reviewed and approved by the release management team, ultimately
 represented by the release management PTL.
-
-
-Attributes
-==========
-
-Tags in the "release" category do not use attributes.

reference/tags/release_cycle-with-milestones.rst

@@ -71,9 +71,3 @@ they match the current release model followed by each code repository.
 There is no need to apply for addition/removal. Changes externally proposed
 will be reviewed and approved by the release management team, ultimately
 represented by the release management PTL.
-
-
-Attributes
-==========
-
-Tags in the "release" category do not use attributes.

reference/tags/release_has-stable-branches.rst

@@ -59,9 +59,3 @@ they match the current release model followed by each code repository.
 There is no need to apply for addition/removal. Changes externally proposed
 will be reviewed and approved by the release management team, ultimately
 represented by the release management PTL.
-
-
-Attributes
-==========
-
-Tags in the "release" category do not use attributes.

reference/tags/release_independent.rst

@@ -61,9 +61,3 @@ they match the current release model followed by each code repository.
 There is no need to apply for addition/removal. Changes externally proposed
 will be reviewed and approved by the release management team, ultimately
 represented by the release management PTL.
-
-
-Attributes
-==========
-
-Tags in the "release" category do not use attributes.

reference/tags/release_managed.rst

@@ -59,9 +59,3 @@ they match the current release model followed by each code repository.
 There is no need to apply for addition/removal. Changes externally proposed
 will be reviewed and approved by the release management team, ultimately
 represented by the release management PTL.
-
-
-Attributes
-==========
-
-Tags in the "release" category do not use attributes.

reference/tags/release_none.rst

@@ -59,9 +59,3 @@ they match the current release model followed by each code repository.
 There is no need to apply for addition/removal. Changes externally proposed
 will be reviewed and approved by the release management team, ultimately
 represented by the release management PTL.
-
-
-Attributes
-==========
-
-Tags in the "release" category do not use attributes.

reference/tags/tc-approved-release.rst

@@ -87,9 +87,3 @@ and TC have agreed to follow for communicating changes to the
    We need a reference to that agreement, when we have it. We also
    need a reference to the deprecation policy the Board adopts, since
    that will influence our policy by at least setting a minimum.
-
-
-Attributes
-==========
-
-None

reference/tags/team_diverse-affiliation.rst

@@ -86,9 +86,3 @@ Deprecation
 
 There is no deprecation period required for this tag.  It can be added or
 removed at any time.
-
-
-Attributes
-==========
-
-This tag has no attributes.

reference/tags/type_library.rst

@@ -58,8 +58,3 @@ Deprecation
 
 There is no deprecation process for tags in the ``type`` namespace. If
 we need to change the type of a project, we can just do that.
-
-Attributes
-==========
-
-None

reference/tags/type_service.rst

@@ -54,8 +54,3 @@ Deprecation
 
 There is no deprecation process for tags in the ``type`` namespace. If
 we need to change the type of a project, we can just do that.
-
-Attributes
-==========
-
-None

reference/tags/vulnerability_managed.rst

@@ -69,9 +69,3 @@ taken to only discontinue vulnerability management for future
 non-patch releases, while continuing to handle vulnerabilities on
 already existing ``stable`` release branches if at all possible
 until such time as they reach end-of-life.
-
-
-Attributes
-==========
-
-None