Open Stack

On Tue, Feb 3, 2015 at 8:04 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

>
>
> On Tue, Jan 27, 2015 at 10:15 AM, Clint Byrum <clint at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150204/4d28e378/attachment.html>