Open Stack

On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote:
> Doug Hellmann wrote:
> > [...]
> > So, my proposal is that we re-evaluate our decision to introduce a tagging system and complicated taxonomy to the *governance* repository, and think about whether the same information can either be found elsewhere already or *should live elsewhere* and needs to be developed there. We can keep the integrated release tag that we have in place now, but we should not adopt any other tags and we should phase out the tag system when we drop the integrated release tag.
> 
> I agree that tag application/removal could be more distributed. The
> original draft for the spec explicitly proposed that the TC delegates
> (some) tag application to other groups, but in those discussions you
> were the one resisting the idea and requiring that the TC retained clear
> oversight :)

The TC should be responsible for evaluating teams and projects that want
to join OpenStack. If we use tags for that purpose, then we should vote
on them. We don't seem to be using tags for that purpose, though (at
least not after we drop the incubated release tag).

> 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.

> 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.

If we need a component list with descriptions, let's build that. It can
be managed by a team of interested parties -- perhaps some of the
operators or deployers, for example. I don't know if we have an existing
place where it would make sense to put it, or if we need a new
repository. We've been applying DRY to the existing projects/programs
list and saying that because we already have a list in the governance
repository we shouldn't repeat that information elsewhere, but we're
also starting to go to a lot of lengths to define a format to hold
information (tags, with metadata, a taxonomy, etc.) that isn't needed
for project governance. That makes me think we're trying to force-fit
this idea into a single list.

> The tagging proposal (only one-month old) has so far received a pretty
> good reception from operators and other downstream users, who see it as
> a way to explain and contribute what type of information matters to
> them. The Technical Committee members are not the only people who can
> propose tags.

I agree that a product matrix with some basic information will be useful
for deployers and operators to find project details, which can then go
into more depth about the issues operators and other downstream users
care about. I just don't think the TC needs to host or maintain that
matrix itself.

When we talk about things going into the governance repository, we
should apply two rules. First, we should consider whether it is
*appropriate* for the TC to be making decisions about the topic.
Subjective tags fail this test. Second, we should consider whether it is
*necessary* for the TC to be making the decision. Objective tags fail
this test.

Doug

> 
> -- 
> Thierry Carrez (ttx)
> 
> __________________________________________________________________________
> 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