Open Stack

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