Thierry Carrez dcad1bc921 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

2015-07-15 12:20:47 +02:00

3.1 KiB

Raw Blame History

This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode

proposed-tag-name (should match the tags/proposed-tag-name.rst filename)

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.

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.

3.1 KiB Raw Blame History