dcad1bc921
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
88 lines
3.1 KiB
ReStructuredText
88 lines
3.1 KiB
ReStructuredText
::
|
|
|
|
This work is licensed under a Creative Commons Attribution 3.0
|
|
Unported License.
|
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
|
|
|
..
|
|
This template should be in ReSTructured text. Please do not delete
|
|
any of the sections in this template. If you have nothing to say
|
|
for a whole section, just write: "None". For help with syntax, see
|
|
http://sphinx-doc.org/rest.html To test out your formatting, see
|
|
http://www.tele3.cz/jbar/rest/rest.html
|
|
|
|
.. Modify the next line to replace <proposed-tag-name> with the tag
|
|
name, then remove this comment.
|
|
|
|
.. _`tag-<proposed-tag-name>`:
|
|
|
|
========================================================================
|
|
proposed-tag-name (should match the tags/proposed-tag-name.rst filename)
|
|
========================================================================
|
|
|
|
..
|
|
Tag names can contain a prefix that represents the category of tag.
|
|
Category prefixes should end in a colon (:). Category prefixes as
|
|
well as tag names should follow a lowercased-hyphen-separated
|
|
style. Examples: 'release:coordinated' or 'docs:api-reference-complete'
|
|
|
|
Introduction paragraph -- a short summary of what this tag will mean.
|
|
|
|
|
|
Application to current projects
|
|
===============================
|
|
|
|
As part of the application you need to go through the exercise of applying
|
|
the proposed tag to at least some subset of the current project list. This
|
|
will serve as an example of how the tag should be applied in the real world.
|
|
You may also submit (as a subsequent change) the corresponding governance
|
|
change to immediately apply the proposed tag to projects.
|
|
|
|
.. tagged-projects:: <tag name>
|
|
|
|
|
|
Rationale
|
|
=========
|
|
|
|
The detailed reason why the OpenStack ecosystem benefits from having this tag
|
|
defined.
|
|
|
|
|
|
Requirements
|
|
============
|
|
|
|
* A list of requirements for granting the tag to an existing project.
|
|
* All the criteria should be objective and predictable.
|
|
* If a tag requires another tag, this should be mentioned here.
|
|
|
|
|
|
Tag application process
|
|
=======================
|
|
|
|
Details of the process to follow to maintain the tag. Are additions/removals
|
|
regularly reviewed, or are they considered only upon request ? Which group
|
|
is involved, and at which frequency ?
|
|
|
|
The process may include requiring feedback from specific groups, delegation
|
|
of tag maintenance from the TC, minimum delays between application and tag
|
|
grant, timeframes where granting or removing the tag is appropriate, etc.
|
|
|
|
If the grant process is different from the removal process, this should also
|
|
be mentioned here.
|
|
|
|
By default, you can use 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
|
|
===========
|
|
|
|
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.
|