On Tue, Feb 3, 2015 at 8:04 PM, Joe Gordon <joe.gord...@gmail.com> wrote:
> > > On Tue, Jan 27, 2015 at 10:15 AM, Clint Byrum <cl...@fewbar.com> 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. >> >> > >> 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. >> > > 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. > > This is similar to what nova is doing with our hypervisor feature > capability matrix in https://review.openstack.org/#/c/136380/ > > We convert a config file into > http://docs-draft.openstack.org/80/136380/7/check/gate-nova-docs/28be8b3//doc/build/html/support-matrix.html > > I really like this Joe. Nice work Daniel. To Jay's response about tag ownership, I think a cross-project team like infra or docs makes sense, but I can't imagine taking it on in docs right now, too many other projects planned. I think in this release the TC may have to suck it up and get it boot strapped, but then make a plan for either distributed maintenance across projects or in a cross-project repo. Anne > > >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Anne Gentle annegen...@justwriteclick.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev