[openstack-dev] Diversity as a requirement for incubation

Jarret Raim jarret.raim at RACKSPACE.COM
Wed Dec 18 15:20:17 UTC 2013


> It is a difficult thing to measure, and I don't think the intent is to set
a hard % 
> for contributions. I think the numbers for Barbican were just illustrating
the 
> fact that the concrete contributions are very coming very heavily from one

> source. That's only one data point, though, and as you point out there are
a 
> lot of other way to contribute.

Agreed. I don't think the conclusion (e.g. Barbican is mostly a Rackspace
driven endeavor at the moment) was incorrect, just that if we are going to
codify the social requirement, we need to have a larger definition than just
code commit %.

> For example, another criteria could be whether the project has core
reviewers 
> from multiple companies, where each is doing some significant proportion
of reviews.

A good option. Still leaves the chicken and the egg problem of how to get
other ATCs interested in reviewing patches for a product they don't work on
that may not be incubated.

 
> I think we've been lucky on that count. I'm not sure how I feel about the
requirement 
> for entering incubation, yet, but I do feel strongly that we need to have
diverse contributors 
> when a project graduates from incubation.

I don't know about lucky or not. If the project has been working in the mode
of not requiring it for years and there have been no problems, why would we
assume they would somehow start? Shouldn't we optimize for the data we have
rather than a guess of future pain? On the technical side, most of the
requirements should be driven from things that have caused pain to OpenStack
projects (rather than sacred cows / opinions / guesses of future pain). They
should be discussed, agreed upon and documented before projects get into the
incubation cycle so that everyone knows the goals going in. The social
requirements seem like they should meet the same standard.

To me, we just need to codify the risk of a project failing to integrate
after incubation. What would be the downside if we incubate a product that
subsequently needs to be removed (for technical or social reasons)? How much
pain does this cause? Is it worth turning away or slowing projects that
solve needs for OpenStack to avoid this pain?

We already have data that says there is a low chance of this happening, so
how much do we want to optimize to reduce that risk before we just accept
that it is there and deal with it when it happens?

There seems to be broad support for the 'required for graduation' bar, which
I'm fine with. It seems like we just need to nail down whether it is
required pre-incubation or not. 


Jarret


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6087 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/1bdd1d95/attachment.bin>


More information about the OpenStack-dev mailing list