Open Stack

Pardon me for being blunt, but I’m still confused why cycles are being spent on semantic wrangling. As you rightly point out, the term is subjective, and that’s the point.

Is there a fear a single set of tags that include both dev and operational aspects confuse consumers of OpenStack? Please clarify.

Thanks
Subbu

> On Jun 19, 2015, at 2:22 AM, Thierry Carrez <thierry at openstack.org> wrote:
> 
> Hi!
> 
> As promised in the Tags meeting, I bring the discussion on naming to the
> list.
> 
> The OpenStack project structure reform that the Technical Committee
> drove over the past year introduced two concepts. The first one is the
> "big tent", the idea that we should consider as "OpenStack projects" all
> the projects produced by the OpenStack Community in the OpenStack Way
> and furthering the OpenStack Mission. But as we expand and cover more
> projects, the picture becomes more confusing to the consumers of this
> ecosystem. Hence the introduction of a second concept: "tags" providing
> clear, actionable information about each project.
> 
> Tags are a class of metadata[1], a controlled vocabulary of labels. 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.
> 
> [1] https://en.wikipedia.org/wiki/Tag_%28metadata%29
> 
> As an example, we wanted to provide actionable information about the
> long-term survivability of a project to the loss of a given corporate
> sponsor. We defined a team:diverse-affiliation tag, based on a set of
> contributor demographics requirements, evaluated using Stackalytics
> metrics. A project meeting the criteria gets the tag. A project not
> meeting the criteria doesn't get the tag. A simple, binary label, this
> is what tags are.
> 
> At the mid-cycle meetup we engaged with the Ops community to get them
> involved in the definition of operational tags. But as the workgroup
> started to work, it focused on defining and providing operational data
> about each project. The state of docs. The state of packaging. The state
> of deployment. The concepts being defined, and the nature of the data
> being built, was quite different from tags. It looked more like
> structured documentation than like labels.
> 
> Then yesterday I had a revelation. Tags are a second-order construct.
> You can't define tags or labels out of the blue. You can only define
> them using existing metrics or documentation as base data. On the
> development side, we have plenty of data available, so we jumped
> directly to defining tags. On the operational side though, the base data
> still needs to be built. It is extremely valuable data. And it is a
> prerequisite for any operational label.
> 
> As an example, take the state of packaging (currently proposed under
> ops:packaged). Which components are packaged ? What is the quality of
> that packaging ? There is no clear data on it so far, it needs to be
> gathered and maintained. If we ever want to define a "well-packaged"
> label, we need that information gathered and available.
> 
> So I would like to take a step back and really consider ops-data and
> tags as two separate, but complementary concepts. Operational data about
> projects is a necessary first step if we ever want to define operational
> tags. You should definitely not limit yourself to the tag framework, and
> define the best ways to gather and convey that information. As a second
> step, someone may propose tags based on that operational data (I have a
> few ideas there already), but that is really a second step.
> 
> That doesn't mean we can't display operational data on the official
> website describing projects. If the Foundation staff sees value in
> displaying that information on www.openstack.org, it can certainly be
> displayed, in parallel to the labels/tags.
> 
> In conclusion, I'd like to suggest that you find an better name to
> describe this operational data about projects, because calling them
> "tags" or "labels" will be confusing in this two-step picture. My
> personal suggestion would be ops-data, but I don't really care which
> color you paint that bikeshed (as long as it's not blue!).
> 
> Thanks for reading so far, hoping we can work within the same framework
> to communicate the best information to all the consumers of our ecosystem.
> 
> -- 
> Thierry Carrez (ttx)
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators