As part of the Big Tent discussion, we have recently started working on a tagging system to allow projects to be described and discovered using data managed by the TC [1]. IIRC, the proposal to have tags came first from Jay’s blog [2], but has evolved as we’ve discussed it as a group, to include extra meta-data about when the tags went into effect or were revoked, and to discuss what sorts of tags are appropriate.
There have been two sorts of categories of tags proposed, objective tags like “included-in-install-guide” or “compute-base” and subjective tags like “production-ready” or “good-enough-for-cern”. As I’ve thought more about this over the last week, I’ve come to the conclusion that it’s not necessary for the TC to vote on the objective tags and that it’s not appropriate for us to vote on the subjective tags. That’s not to say the tags aren’t useful, just that I don’t think we want them in the governance repository. All of the examples of objective tags we have discussed so far are really short-hand for information that should be discoverable by looking at project documentation. To find if something is documented in the installation guide, read the table of contents. To learn about the dependencies of a project, look at it’s installation instructions. To learn if a distribution includes the packages for a given project, look at the distribution's feature list. None of those things need to be voted on by the governance body. The more subjective tags are meant to help deployers make decisions about when and how to use projects -- "Is project X 'good/stable/mature/scalable enough' for me to use?” We likely to get bogged down in describing what exactly we mean by these sorts of terms, as we try convert the subjective tag to objective criteria to use to apply the it. If we manage to come up with those objective criteria, we’re back to a point where anyone could just write the answer down in documentation without needing a vote. If we don’t come up with objective criteria, then we have the governing body making value judgements about what deployers *should* want rather than what they *do* want. We would be better off with deployers sharing information with each other by writing about their experiences online, via blogs or deployment guides or other outlets, than having the TC try to make those sorts of decisions for them. 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. Doug [1] https://review.openstack.org/#/q/project:openstack/governance+branch:master+topic:tag-template,n,z [2] http://www.joinfu.com/2014/09/so-what-is-the-core-of-openstack/ __________________________________________________________________________ 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
