Open Stack

On 07/15/2015 11:25 AM, Joshua Harlow wrote:
> So I've been following the TC work on tags, and have been slightly
> confused by the whole work, so I am wondering if I can get a
> 'explainlikeimfive' (borrowing from reddit terminology) edition of it.

I'll try :)

You need to think of "tags" as the labels on the boxes containing your
toys: you'll have a box with legos, one box with dolls, one box with
bicycle parts, one with star wars figurines etc. Each box with a label
outside so you can read (at 5 you may be able to read) what is in the
box before you open it.

Does that make sense?

You may think that the tags are to identify the toys you like the most
but that's not the purpose. You may like Skywalker figurine but dislike
Yoda, but they're both going to be in the starwars box. Starwars is an
objective way for dad and your friends to understand which toys go in
which bucket. Since you may like something today and not tomorrow, and
since dad can't read your mind we don't use labels such as "things I
like a lot" or "things I hate" because those are subjective valuations.

Are you still there? :)

> I always thought tags were going to be something like:
>
> http://i.imgur.com/rcAnMkX.png

The graphic you used obviously carries subjective meaning, which tags
are never meant to be and hopefully never will.

The 'tags' are defined on the spec:

http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html

On that spec there is spelled out the problem that the tags are
introduced to solve.  Tags are to represent a precise *taxonomy* to
navigate the OpenStack ecosystem, to help readers understand how a
project is managed (does it have a vulnerability team assigned? does it
keep a stable branch? what's the release model? Is it overseen by the
TC? etc). As the spec says:

    the landscape [used to be]is very simple: you’re in the integrated
    release, or you’re not. But since there was only one category (or
    badge of honor), it ended up meaning different things to different
    people.


In Thierry's words to "[Openstack-operators] [tags] Ops-Data vs.
Ops-Tags", June 16 2015:

    They come with a definition, a set of requirements that a project
    must fulfill to be granted the label. Ideally the requirements are
    objective, based on available documentation and metrics. But the
    tag definition itself remains subjective.


The tags are called to describe objectively each project. So, for
example, if you want to know which project maintain a stable branch, you
see the list on:

http://governance.openstack.org/reference/tags/release_has-stable-branches.html

You want to see if projects are libraries, middleware or client:

http://governance.openstack.org/reference/tags/type_library.html

Are you curious to see which projects constitute the release approved by
the TC?

http://governance.openstack.org/reference/tags/tc-approved-release.html

Tags can be proposed by anyone, not only by the TC and they get
discussed and voted on gerrit. The proposed tags need to be as objective
as possible. And there is a working group
(https://etherpad.openstack.org/p/ops-tags-June-2015) among operators
trying to define tags that may help operators to judge if a project is
good for them to use or not.

HTH
stef