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.

    - 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

Reply via email to