[openstack-dev] Avoiding regression in project governance

Jay Pipes jaypipes at gmail.com
Tue Mar 10 18:32:28 UTC 2015


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:thierry at openstack.org] Sent: Tuesday, March 10, 2015 11:00
> AM To: openstack-dev at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list