<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 27, 2015 at 10:15 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Excerpts from Thierry Carrez's message of 2015-01-27 02:46:03 -0800:<br>
<span class="">> Doug Hellmann wrote:<br>
> > On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote:<br>
> > [...]<br>
> >> I'm open to alternative suggestions on where the list of tags, their<br>
> >> definition and the list projects they apply to should live. If you don't<br>
> >> like that being in the governance repository, what would have your<br>
> >> preference ?<br>
> ><br>
> > From the very beginning I have taken the position that tags are by<br>
> > themselves not sufficiently useful for evaluating projects. If someone<br>
> > wants to choose between Ceilometer, Monasca, or StackTach, we're<br>
> > unlikely to come up with tags that will let them do that. They need<br>
> > in-depth discussions of deployment options, performance characteristics,<br>
> > and feature trade-offs.<br>
><br>
> They are still useful to give people a chance to discover that those 3<br>
> are competing in the same space, and potentially get an idea of which<br>
> one (if any) is deployed on more than one public cloud, better<br>
> documented, or security-supported. I agree with you that an<br>
> (opinionated) article comparing those 3 solutions would be a nice thing<br>
> to have, but I'm just saying that basic, clearly-defined reference<br>
> project metadata still has a lot of value, especially as we grow the<br>
> number of projects.<br>
><br>
<br>
</span>I agree with your statement that summary reference metadata is useful. I<br>
agree with Doug that it is inappropriate for the TC to assign it.<br>
<span class=""><br>
> >> That said, I object to only saying "this is all information that can be<br>
> >> found elsewhere or should live elsewhere", because that is just keeping<br>
> >> the current situation -- where that information exists somewhere but<br>
> >> can't be efficiently found by our downstream consumers. We need a<br>
> >> taxonomy and clear definitions for tags, so that our users can easily<br>
> >> find, understand and navigate such project metadata.<br>
> ><br>
> > As someone new to the project, I would not think to look in the<br>
> > governance documents for "state" information about a project. I would<br>
> > search for things like "install guide openstack" or "component list<br>
> > openstack" and expect to find them in the documentation. So I think<br>
> > putting the information in those (or similar) places will actually make<br>
> > it easier to find for someone that hasn't been involved in the<br>
> > discussion of tags and the governance repository.<br>
><br>
> The idea here is to have the reference information in some<br>
> Gerrit-controlled repository (currently openstack/governance, but I'm<br>
> open to moving this elsewhere), and have that reference information<br>
> consumed by the <a href="http://openstack.org" target="_blank">openstack.org</a> website when you navigate to the<br>
> "Software" section, to present a browseable/searchable list of projects<br>
> with project metadata. I don't expect anyone to read the YAML file from<br>
> the governance repository. On the other hand, the software section of<br>
> the <a href="http://openstack.org" target="_blank">openstack.org</a> website is by far the most visited page of all our web<br>
> properties, so I expect most people to see that.<br>
><br>
<br>
</span>Just like we gather docs and specs into single websites, we could also<br>
gather project metadata. Let the projects set their tags. One thing<br>
that might make sense for the TC to do is to elevate certain tags to<br>
a more important status that they _will_ provide guidance on when to<br>
use. However, the actual project to tag mapping would work quite well<br>
as a single file in whatever repository the project team thinks would<br>
be the best starting point for a new user.<br></blockquote><div><br></div><div>One way we can implement this is, have the TC manage a library  that converts a file with tag data into a document, along with a list of default tags, and each project can import that library and include it in its docs.  This way the TC can suggest tags that make sense, but its up to individual projects to apply them.</div><div><br></div><div>This is similar to what nova is doing with our hypervisor feature capability matrix in  <a href="https://review.openstack.org/#/c/136380/">https://review.openstack.org/#/c/136380/</a></div><div><br></div><div>We convert a config file into <a href="http://docs-draft.openstack.org/80/136380/7/check/gate-nova-docs/28be8b3//doc/build/html/support-matrix.html">http://docs-draft.openstack.org/80/136380/7/check/gate-nova-docs/28be8b3//doc/build/html/support-matrix.html</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>