On 03/10/2015 12:29 PM, Russell Bryant wrote:
The TC is in the middle of implementing a fairly significant change in
project governance.  You can find an overview from Thierry on the
OpenStack blog [1].

Part of the change is to recognize more projects as being part of the
OpenStack community.  Another critical part was replacing the integrated
release with a set of tags.  A project would be given a tag if it meets
some defined set of criteria.

The two things are not mutually exclusive.

Also, the tags are intended to be informative, not "granted by the TC". As Thierry mentioned elsewhere, the job of defining these tags and applying them to projects is a never-ending thing, not something that needs to be completed before allowing new projects into the openstack/ code namespace.

I feel that we're at a very vulnerable part of this transition.  We've
abolished the incubation process and integrated release.  We've
established a fairly low bar for new projects [2].  However, we have not
yet approved *any* tags other than the one that reflects which projects
are included in the final integrated release (Kilo) [3].  Despite the
previously discussed challenges with the integrated release,
it did at least mean that a project has met a very useful set of
criteria [4].

a) I believe the integrated release moniker held much value previously

b) The existing OpenStack projects that were in the "integrated release" are *already* tagged with the integrated-release tag, and no new projects will be tagged with that.

c) There is no connection at all between the "bar" for projects to get into the openstack/ code namespace and the tags. The tags are informative and can be applied at any time to a project. They are not a "blessing" by the TC.

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).

Again, tags aren't criteria that we use to determine whether a project is worthy of being in the openstack/ code namespace. The entire point of the Big Tent model was to move away from the TC blessing projects and instead use tags to decorate a project with some useful information. In other words, the point of Big Tent was to decouple these tags from the application process.

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 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.

In contrast, I see no reason to prevent new projects from applying. There's nothing about the new application requirements that mentions tags or the need to tag a project at application time.



[1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/
[2] http://governance.openstack.org/reference/new-projects-requirements.html
[3] http://governance.openstack.org/reference/tags/index.html

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to