On 06/01/2015 04:07 AM, Tom Fifield wrote:
Hi all,
Thank you very much for officially kicking off the Ops Tags Team at the
Vancouver summit!
Based on our discussions, I've made a bit of progress. We now have a
* wiki page: https://wiki.openstack.org/wiki/Operations/Tags
* repository: https://github.com/stackforge/ops-tags-team
... and ... a first attempt at writing up those tags we discussed at the
meeting:
* Ops:docs:install-guide: https://review.openstack.org/#/c/186638/
* Ops:Packaged: https://review.openstack.org/#/c/186633/
Please jump on the code review system and add your comments!
Hi Tom,
I have some serious concerns about how the OpsTags team is defining what
a tag is.
From the wiki page above, you write:
When applied to a project, Tags are comprised of a name (eg
"Ops:Deployment-Widespread", "Ops:Config-Recipes-Available",
"Ops:Packaged"), a value (eg "92%", "yes", "Ubuntu, Redhat and SUSE")
and if applicable a description of why the project has that value.
This isn't at all what tags are supposed to be. Tags are not intended to
contain a "value", nor should a tag contain "a description of why the
project has that value".
Tags are simple strings.
They do not have a schema to them. They do not have a value part. They
do not have any caveats or exceptions.
To use an example of a tag that already exists... let's take the
team:diverse-affiliation tag [1]. This tag's definition tells the
audience that the project's contributor team has a certain level of
diversity to it -- in review and commit % over the last release cycle.
The tag itself does not indicate the % of reviews or commits from the
highest contributor -- in other words, the tag doesn't look like this:
team:diverse-affiliation:42%
That's encoding a value in a tag and that's not what tags are about. Tag
definitions inform the reader that if a tag is applied to a project,
then that project meets the conditions laid out in the tag definition.
That's it. Nothing more, nothing less.
Let's please try to keep the Ops Tags bound to the same definition of a
tag. Do not have a value portion of a tag. The tag definition file
should clearly explain what conditions were met if a project has that
tag applied to it. No caveats or exceptions needed.
Best,
-jay
[1]
https://github.com/openstack/governance/blob/master/reference/tags/team_diverse-affiliation.rst
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
