Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
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
Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
On 2015-02-03 22:12:09 -0500 (-0500), Jay Pipes wrote: On 01/27/2015 01:15 PM, Clint Byrum wrote: [...] 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. [...] Originally, I proposed that the tag data be managed by the project-config-core team in much the same way that new Gerrit/Jeepyb project applications are handled. For the same reasons that the TC is uncomfortable making these decisions about what tags to assign to what repos I am uncomfortable, as part of the Infra team e.g. project-config-core in Gerrit, being the decision making body on whether a repo contains production ready software, has sufficient testing, is thoroughly documented, is security-audited and keeps up with their vulnerability reports, et cetera. Acting as a gatekeeper and proxy for the actual stakeholders (User Committee/Operators, QA team, Docs team, VMT/OSSG, and so on) is probably okay but does sound a bit tedious. -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
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 __ 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
Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
On 01/27/2015 01:15 PM, Clint Byrum 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. As do I. I think we can easily over-think the implementation of this ostensibly simple idea. Originally, I proposed that the tag data be managed by the project-config-core team in much the same way that new Gerrit/Jeepyb project applications are handled. Best, -jay 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. __ 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
Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
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. __ 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
Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
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. 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. 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. If I understand you correctly, you'd like to have the project teams list (previously known as programs) in the governance repository, together with the list of their associated code repositories. Then you would have a duplicate list of code repositories, with their associated tag metadata, in some other repository. I understand the limits of DRY, but that duplication still sounds like a maintenance nightmare (especially given how often the repository list is updated)... How do you make sure that repositories in A are in B ? Some check test at the gate ? Alternatively we could have the project teams / code repositories association live in the other repository and just duplicate the project teams list, which arguably should be smaller. That means we would also delegate the repository scope sanity-check to the other repository maintainers, but I'm fine with that. We could have one file per project team and a check test that validates the project team exists in the governance repository. The only (small) issue with that option is that code repositories translate into ATCs, which translate into TC voters, so this is arguably a governance thing. 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
Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
On Tue, Jan 27, 2015, at 05:46 AM, Thierry Carrez wrote: 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. Right. My main argument is that this isn't something for the TC to do, not that it shouldn't be done. I'm not convinced it's that useful, but I don't have a problem if someone else does 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. Right, I didn't think anyone would be reading the YAML file either. I didn't realize we were planning to publish the information anywhere other than the published version of the governance docs. That's not really the crux of my argument, though. 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. If I understand you correctly, you'd like to have the project teams list (previously known as programs) in the governance repository, together with the list of their associated code repositories. Then you would have a duplicate list of code repositories, with their associated tag metadata, in some other repository. I understand the limits of DRY, but No. I don't think a product list needs to have a list of repositories. It only needs a list of products. In some cases those map 1:1, but not in all cases. In any case, I would expect the Nova team to want their product called Nova and not openstack/nova. For teams with more than one product, or more than one repository creating a single product, we need the product names somewhere anyway. So let's just make a list of product names somewhere. We can use tags or sentences or whatever to describe them. But doing that is just writing product documentation. It isn't project governance. that duplication still sounds like a maintenance nightmare (especially given how often the repository list
[openstack-dev] [tc] do we really need project tags in the governance repository?
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
Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
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
Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
(this may have been sent multiple times as I experience email issues, sorry for the noise if that's indeed the case) 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 :) 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 ? 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. 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. -- 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
Re: [openstack-dev] [tc] do we really need project tags in the governance repository?
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 :) 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 ? 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. 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. -- 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
