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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
