Open Stack

On Wed, Dec 18, 2013 at 8:06 AM, Jarret Raim <jarret.raim at rackspace.com>wrote:

>
>
> > -----Original Message-----
> > From: Sylvain Bauza [mailto:sylvain.bauza at bull.net]
> > Sent: Wednesday, December 18, 2013 5:04 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] Diversity as a requirement for incubation
> >
> > Le 18/12/2013 11:40, Thierry Carrez a écrit :
> > > I guess there are 3 options:
> > >
> > > 1. Require diversity for incubation, but find ways to bless or
> > > recommend projects pre-incubation so that this diversity can actually
> > > be achieved
> > >
> > > 2. Do not require diversity for incubation, but require it for
> > > graduation, and remove projects from incubation if they fail to
> > > attract a diverse community
> > >
> > > 3. Do not require diversity at incubation time, but at least judge the
> > > interest of other companies: are they signed up to join in the future ?
> > > Be ready to drop the project from incubation if that was a fake
> > > support and the project fails to attract a diverse community
> > >
> > > Personally I'm leaning towards (3) at the moment. Thoughts ?
> >
> > I would vote for (1). FWIW, incubated projects are robust enough to fail
> from
> > a resource perspective.
> > That definitely goes to what an incubated project is : to me, incubated
> > projects *will* be integrated, but they currently aren't due to some
> > *technical* (code compliancy, unittesting, frameworks, integration with
> > other projects) concerns.
>
> I would go the entirely opposite direction. It is difficult to get
> community
> support for unrecognized projects, especially when that support is usually
> in the form of FTEs from interested companies. Without some assurance that
> the project will make it into OpenStack, it is significantly more difficult
> to get companies to assign resources. Coming up with another status doesn't
> seem to solve that problem unless that status is 'this will be in OpenStack
> soon, start collaborating' which, to me, is what incubation is designed to
> do. If the new status requires no investment from OpenStack, then it
> doesn't
> signal any strong commitment, making it less clear that other vendors
> should
> support the effort.
>
> I would say that fixing some technical issues pre-incubation seems fine,
> but
> expecting every project to have a diverse (as in multi-vendor) team before
> the project has achieved any type of status is difficult. Also, any general
> technical requirements should be documented beforehand. For Barbican, there
> seems to be a lot of goalpost moving in that people just say what they want
> and there is very little way for us to know what those requirements will
> be.
>
>
> Additionally, measuring diversity of a project is also difficult. The
> current measure being used is commit percentage, which is terrible. If a
> project bakes for a while with a core set of developers, it will take a
> long
> time for new contributors to make a dent in the percentages. It also
> incentives bad behavior, e.g. wrapping up lots of small commits into one
> big
> one, etc. We need more inclusive measures, maybe including intent to
> deploy,
> etc.
>

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.

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



>
> Barbican has been open since its inception. It has never been closed or
> limited in any way. However, we didn't really start getting interest until
> we reached our MVP. We have interest now, but even though people have
> started contributing, it will take a while to chip away at the commit
> percentages.
>
> For me, I would be fine with #2 or #3 (they seem very similar), but I don't
> think #1 is realistic. Keep in mind that many of the current OpenStack
> programs & projects were incubated without diverse communities. This
> doesn't
> seem to have caused outsized headaches.
>

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.


> > If we assess that incubated projects could not part of Openstack one day
> or
> > so, that won't help community adoption and/or resources dedication.
>
> If something gets kicked out of incubation, it is explicitly because it
> didn't garner any additional community support. By being in incubation, the
>

A project might not graduate for technical reasons, as well. That's likely
to happen because of a lack of community involvement, but not necessarily.

Doug



> project becomes the owner of a particular set of features. If no one joins,
> it's either because the no one is interested in that feature set, the
> project's community is not receptive or the project already meets the needs
> of the user and they don't need to contribute devs. I see this as happening
> very rarely, but only if we get better measures for diversity.
>
>
> Jarret
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/b5fbe691/attachment.html>