Open Stack

On 01/27/2015 01:15 PM, Clint Byrum wrote:
> Excerpts from Thierry Carrez's message of 2015-01-27 02:46:03 -0800:
>> Doug Hellmann wrote:
>>> On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote:
>>> [...]
>>>> I'm open to alternative suggestions on where the list of tags, their
>>>> definition and the list projects they apply to should live. If you don't
>>>> like that being in the governance repository, what would have your
>>>> preference ?
>>>
>>>  From the very beginning I have taken the position that tags are by
>>> themselves not sufficiently useful for evaluating projects. If someone
>>> wants to choose between Ceilometer, Monasca, or StackTach, we're
>>> unlikely to come up with tags that will let them do that. They need
>>> in-depth discussions of deployment options, performance characteristics,
>>> and feature trade-offs.
>>
>> They are still useful to give people a chance to discover that those 3
>> are competing in the same space, and potentially get an idea of which
>> one (if any) is deployed on more than one public cloud, better
>> documented, or security-supported. I agree with you that an
>> (opinionated) article comparing those 3 solutions would be a nice thing
>> to have, but I'm just saying that basic, clearly-defined reference
>> project metadata still has a lot of value, especially as we grow the
>> number of projects.
>
> I agree with your statement that summary reference metadata is useful. I
> agree with Doug that it is inappropriate for the TC to assign it.

As do I. I think we can easily over-think the implementation of this 
ostensibly simple idea.

Originally, I proposed that the tag data be managed by the 
project-config-core team in much the same way that new Gerrit/Jeepyb 
project applications are handled.

Best,
-jay

>>>> That said, I object to only saying "this is all information that can be
>>>> found elsewhere or should live elsewhere", because that is just keeping
>>>> the current situation -- where that information exists somewhere but
>>>> can't be efficiently found by our downstream consumers. We need a
>>>> taxonomy and clear definitions for tags, so that our users can easily
>>>> find, understand and navigate such project metadata.
>>>
>>> As someone new to the project, I would not think to look in the
>>> governance documents for "state" information about a project. I would
>>> search for things like "install guide openstack" or "component list
>>> openstack" and expect to find them in the documentation. So I think
>>> putting the information in those (or similar) places will actually make
>>> it easier to find for someone that hasn't been involved in the
>>> discussion of tags and the governance repository.
>>
>> The idea here is to have the reference information in some
>> Gerrit-controlled repository (currently openstack/governance, but I'm
>> open to moving this elsewhere), and have that reference information
>> consumed by the openstack.org website when you navigate to the
>> "Software" section, to present a browseable/searchable list of projects
>> with project metadata. I don't expect anyone to read the YAML file from
>> the governance repository. On the other hand, the software section of
>> the openstack.org website is by far the most visited page of all our web
>> properties, so I expect most people to see that.
>>
>
> Just like we gather docs and specs into single websites, we could also
> gather project metadata. Let the projects set their tags. One thing
> that might make sense for the TC to do is to elevate certain tags to
> a more important status that they _will_ provide guidance on when to
> use. However, the actual project to tag mapping would work quite well
> as a single file in whatever repository the project team thinks would
> be the best starting point for a new user.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>