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