Re: [openstack-dev] [tc] do we really need project tags in the governance repository?

2015-02-04 Thread Anne Gentle
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?

2015-02-04 Thread Jeremy Stanley
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?

2015-02-03 Thread Joe Gordon
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?

2015-02-03 Thread Jay Pipes

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?

2015-01-27 Thread Clint Byrum
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?

2015-01-27 Thread Thierry Carrez
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?

2015-01-27 Thread Doug Hellmann


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 

Re: [openstack-dev] [tc] do we really need project tags in the governance repository?

2015-01-26 Thread Doug Hellmann


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?

2015-01-26 Thread Thierry Carrez
(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?

2015-01-26 Thread Thierry Carrez
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