Open Stack

Been sort of chewing on the various opinions expressed ...
clearly this decision needs to be one of the first things to come
out of  the ops-tags team

I think we could do most of what we need with binary tags if those
were hierarchical ie this tag means those other five are also applied,
but multiplies the number of tags by a lot and I think multiplies
complexity especially since many (perhaps most) of our tags will
require human judgement.

Having a common schema for ops tags may allow us to retain the
richness of the content while not unnecessarily complicating their use
for example

<tagname>:
  value: <string>
  bug_list: [<maybe empty url_list>]
  description: <maybe empty string>
  exceptions: <maybe empty string>

Of these I'm not sure description and exceptions are needed but I'm
pretty sure value and bug list are, and once we have a data structure
beyond binary or key-value adding those two doesn't raise complexity
significantly and does add some value.

Once we do set a precedent for either binary tags or rich tags I have a
feeling it will stick hard, especially if we choose binary.

If we really find we can define all the tags we want with just a true or false
value then there's no point in complicating things and the additional info could
likely be provided in a wiki page or something as a concordance to the tags
rather than in the tag itself.

So I'd like to challenge those of us currently advocating structured rather
than binary tags to come up with tag examples we feel are necessary and
nonbinary.

The install-guide tag likely could be binary, though enriching 'false'
with links to less official or work in progress documentation could be
valuable a web search could hopefully get you that, exceptions might
be useful if a distro does something that breaks an install guide for
that one case and if there is an exception a bug pointer would be
ideal, IMO.

The packaged tag I think is a stronger case for structured content.
Imagine we break it down to the obvious packaged-deb and packaged-rpm
there's still much complexity back there and I think we'd need
exceptions.

-Jon

On Wed, Jun 3, 2015 at 1:29 PM, Richard Raseley <richard at raseley.com> wrote:
> Thierry Carrez wrote:
>>
>> It's visible in the tag description. Each tag is backed by a precise
>> definition that explains what the tag means.
>>
>> Tags as designed are labels, not metrics. We define what "well-packaged"
>> means, and then apply that label to projects that fit the bill.
>>
>> If we mix the messaging by making tags be both labels and metrics, then
>> it will be extra-hard to make a project navigation website to expose both.
>>
>> That said, the Ops tags WG is pretty much on the same line -- the
>> discussion we had in Vancouver was that we should define subjectively
>> what "well-packaged" means, and than apply it objectively. Same for the
>> other ops tags. So I think we are actually on the same line...
>
>
> I just wanted to add my voice to say that, as an operator, I completely
> agree with what both you and Jay are saying here.
>
> The tags do offer value (I've come around since the mid-cycle operators
> meet-up), and I think we should remain consistent in terms of defining the
> model around them as a binary indication of compliance with a particular set
> of criteria.
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators