On 03/10/2015 02:28 PM, Gabriel Hurley wrote:
Blocking the acceptance of new projects seems punitive and against
the spirit of the big tent. Classification (tagging) can be done at
any point, and is hardly fixed in stone. You can refine tags as
needed.
To put it harshly: it is a failure of both leadership and process to
have stripped out the old process and set a low bar only to insist
that no one may be accepted under the new criteria because you
haven't defined the rest of the process yet.
Even more concerning is the sentiment of "projects we want to
consciously drop" from Russell's original email. I realize that was
meant to apply to whatever becomes the "integrated release" tag, yet
still... the point of the big tent is not to exclude; the big tent is
meant to *include and classify* so that the community, operators,
distros, and vendors could make the best choices for themselves.
So I agree that these projects are a great litmus test for what kind
of tags you need, but at this point I don't think you have a leg to
stand on for not accepting projects that meet the current criteria.
The bar for acceptance is in the governance documents.
A freeze seems unjustifiable and dragging your feet seems
unnecessary, at least unless you all plan on changing the governance
yet again.
Amen. +1.
-jay
- Gabriel
-----Original Message----- From: Thierry Carrez
[mailto:thie...@openstack.org] Sent: Tuesday, March 10, 2015 11:00
AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
Avoiding regression in project governance
Russell Bryant wrote:
[...] We now have several new project proposals. However, I
propose not approving any new projects until we have a tagging
system that is at least far enough along to represent the set of
criteria that we used to apply to all OpenStack projects (with
exception for ones we want to consciously drop). Otherwise, I
think it's a significant setback to our project governance as we
have yet to provide any useful way to navigate the growing set of
projects.
The resulting set of tags doesn't have to be focused on
replicating our previous set of criteria. The focus must be on
what information is needed by various groups of consumers and tags
are a mechanism to implement that. In any case, we're far from
that point because today we have nothing.
I agree that we need tags to represent the various facets of what was
in the integrated release concept.
I'm not sure we should block accepting new project teams until all
tags are defined, though. That sounds like a way to stall forever. So
could you be more specific ? Is there a clear set of tags you'd like
to see defined before we add new project teams ?
I can't think of any good reason to rush into approving projects
in the short term. If we're not able to work out this rich
tagging system in a reasonable amount of time, then maybe the whole
approach is broken and we need to rethink the whole approach.
The current plan for the Vancouver Design Summit is to only give
space to "OpenStack" projects (while non-OpenStack projects may get
space in "ecosystem" sessions outside of the Design Summit). So it's
only fair for those projects to file for recognition before that
happens.
-- 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
__________________________________________________________________________
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
