Open Stack

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.

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.


Regards,


Tom