Open Stack

On Sun, Nov 18, 2012 at 11:19 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> On Sun, 2012-11-18 at 00:20 -0600, Anne Gentle wrote:
>> All this said, I think paragraph three is the only area where a
>> revised motion helps me come to consensus. I want a welcoming,
>> worthwhile incubation process, that's important to me. What's also
>> important is that we are ready to define the responsibilities to exit
>> incubation. This sentence just isn't enough... "demonstrate" and
>> "suitability" and "inclusion" and "coordinated" aren't enough...
>>
>> "We see Incubation as a trial period where promising projects have the
>>   opportunity to demonstrate their suitability for inclusion in our
>>   coordinated releases."
>
> Care to propose a stronger wording? I suspect there's general consensus
> that Incubation should be no cakewalk and that the bar should actually
> be quite high for projects to exit Incubation.

Sure:

"We see Incubation as a trial period where projects interested in
joining the OpenStack community have the opportunity to demonstrate
their willingness to meet OpenStack standards for coordinated releases
and project management. The Incubation period is time-based and
intends to provide a extended evaluation effort while providing the
project shared resources both for consumption and contribution. While
evaluation criteria for incubation exit are still needed, the ideal
incubation process affords time for both the project itself and the
community. Ideally projects exiting incubation give a proven,
measurable ability to enable OpenStack infrastructure and services, to
increase adoption for OpenStack and possibly across multiple OpenStack
clouds, and prove it has potential for wide usefulness."

A couple of reasons for the extended wording:

-acknowledges the need to define the process further
-enables several more definitions of exit/promotion/next life

Thanks all.
Anne

> Back to the docs example again, it may be a case that there needs to be
> high bar for the docs required to exit Incubation (be it API, config,
> deployer, user, etc. docs) and that we're not so much saying that the
> developers on the project must write those docs but rather that if the
> project isn't interesting enough to attract a certain level of docs
> contributions, then it's just not interesting enough, period.

Yep, docs are a good example but can be an outlier due to the "release
definition" problem I noted. I want to be sure I'm clear-headed about
the real goals for project inclusion, to make OpenStack better, not to
make OpenStack docs better. :)

> Cheers,
> Mark.
>