Open Stack

Hi TC members,

Just a heads-up: I (and others) have been following the "ops tags"
workgroup discussions and reviews, and it appears what they are working
on is slightly different from the framework we defined.

Basically we defined a "tag" framework where we define a label, and the
conditions to apply that label. We have provisions to pass extra
information ("attributes"), but the label itself is pretty binary: you
either have it or you don't.

Part of the rationale behind that simplicity was the idea that binary
tags make it pretty simple to create a project/tag navigation website.
It also forces us to define what matters, rather than leave it as an
exercise to the reader.

The operators want to work on providing their own information about
projects, which I think is a great thing. The "operators perspective" on
projects if you will. They are calling their work "tags", but what they
are currently defining are more "areas" which can be described in
various ways (multiple values rather than binary) and will routinely use
attributes to convey information. It's closer to structured documentation.

A few examples to illustrate the difference:

Ops are defining a "packaging" area that may be "good", "beginning",
"warning" or "none", and attributes listing which distributions do packages.

In a tag world, we'd just define a "well-packaged" label, and apply it
to the projects that fit the definition.

Other example:

We have been defining "team:diverse-affiliation" with an opinionated
definition of what that means to be a diverse team. The Ops would rather
define "diversity" and score it using a % value.

We have been defining a series of "release:" tags that apply to projects
following given release models. The Ops would rather define
"release-model" and have it express the exact model followed using
various attributes.

So their approach is basically different from ours, and I think we can't
call both "tags" and consider them being the same thing.

There are 3 ways out of this:

1/ We can try to convince them to make their areas more like tags
2/ We can overhaul our tags so that they look more like areas
("diversity", "release-model")
3/ We can let them coexist (TC provides tags, Ops provide areas) but
stop calling them the same, because that's confusing.

In case we pursue #3, we could still define tags on top of Ops data. The
main drawback of #3 is that it makes the project navigation website
substantially more complex (must exhibit both types of data).

Food for thoughts, we'll discuss that in future meetings.

-- 
Thierry Carrez (ttx)