> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev