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, Feb 3, 2015 at 8:04 PM, Joe Gordon wrote: > > > On Tue, Jan 27, 2015 at 10:15 AM, 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. >> >> > >> 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.op
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?
On Tue, Jan 27, 2015 at 10:15 AM, 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. > > > >> 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?
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?
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
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 depl
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
