Open Stack

On 06/02/2015 10:29 AM, Tom Fifield wrote:
> On 02/06/15 22:18, Jay Pipes wrote:
>> On 06/01/2015 04:07 AM, Tom Fifield wrote:
>>> Hi all,
>>>
>>> Thank you very much for officially kicking off the Ops Tags Team at the
>>> Vancouver summit!
>>>
>>> Based on our discussions, I've made a bit of progress. We now have a
>>>
>>> * wiki page: https://wiki.openstack.org/wiki/Operations/Tags
>>> * repository: https://github.com/stackforge/ops-tags-team
>>>
>>>
>>> ... and ... a first attempt at writing up those tags we discussed at the
>>> meeting:
>>>
>>>
>>> * Ops:docs:install-guide: https://review.openstack.org/#/c/186638/
>>>
>>> * Ops:Packaged: https://review.openstack.org/#/c/186633/
>>>
>>>
>>> Please jump on the code review system and add your comments!
>>
>> Hi Tom,
>>
>> I have some serious concerns about how the OpsTags team is defining what
>> a tag is.
>>
>>  From the wiki page above, you write:
>>
>> When applied to a project, Tags are comprised of a name (eg
>> "Ops:Deployment-Widespread", "Ops:Config-Recipes-Available",
>> "Ops:Packaged"), a value (eg "92%", "yes", "Ubuntu, Redhat and SUSE")
>> and if applicable a description of why the project has that value.
>>
>> This isn't at all what tags are supposed to be. Tags are not intended to
>> contain a "value", nor should a tag contain "a description of why the
>> project has that value".
>>
>> Tags are simple strings.
>>
>> They do not have a schema to them. They do not have a value part. They
>> do not have any caveats or exceptions.
>>
>> To use an example of a tag that already exists... let's take the
>> team:diverse-affiliation tag [1]. This tag's definition tells the
>> audience that the project's contributor team has a certain level of
>> diversity to it -- in review and commit % over the last release cycle.
>> The tag itself does not indicate the % of reviews or commits from the
>> highest contributor -- in other words, the tag doesn't look like this:
>>
>> team:diverse-affiliation:42%
>>
>> That's encoding a value in a tag and that's not what tags are about. Tag
>> definitions inform the reader that if a tag is applied to a project,
>> then that project meets the conditions laid out in the tag definition.
>> That's it. Nothing more, nothing less.
>>
>> Let's please try to keep the Ops Tags bound to the same definition of a
>> tag. Do not have a value portion of a tag. The tag definition file
>> should clearly explain what conditions were met if a project has that
>> tag applied to it. No caveats or exceptions needed.
>
> Hi Jay,
>
> Thanks for sharing your concerns.
>
> I think providing information to operators is the aim and the way the
> ops tags team has agreed to do this is reasonable in achieving it. I'm
> not worried if the ops tags end up looking quite a bit different to the
> ones under TC governance provided we meet this aim.

Please, no. We should not have ops tags that are different than other 
tags for no good reason.

> It might help to look at some of the examples being discussed in the
> code review system or on the etherpad to get an idea of the kind of
> stuff the team's looking into. The text on the wiki was put together in
> rather a hurry and will be evolving as we work stuff out.

Sure, I plan on reviewing all of them.

Best,
-jay