Re: [openstack-dev] Diversity as a requirement for incubation
+1 -bryan On Wed, Dec 18, 2013 at 10:22 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/18/2013 12:34 PM, Doug Hellmann wrote: I have more of an issue with a project failing *after* becoming integrated than during incubation. That's why we have the incubation period to begin with. For the same reason, I'm leaning towards allowing projects into incubation without a very diverse team, as long as there is some recognition that they won't be able to graduate in that state, no matter the technical situation. This precisely sums up my view as well. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
Le 18/12/2013 16:37, Steven Dake a écrit : In the early days of incubation requests, I got the distinct impression managers at companies believed that actually getting a project incubated in OpenStack was not possible, even though it was sparsely documented as an option. Maybe things are different now that a few projects have actually run the gauntlet of incubation and proven that it can be done ;) (see ceilometer, heat as early examples). But I can tell you one thing for certain, an actual incubation commitment from the OpenStack Technical Committee has a huge impact - it says Yes we think this project has great potential for improving OpenStack's scope in a helpful useful way and we plan to support the program to make it happen. Without that commitment, managers at companies have a harder time justifying RD expenses. That is why I am not a big fan of approach #3 - companies are unlikely to commit without a commitment from the TC first ;-) (see chicken/egg in your original argument ;) We shouldn't be afraid of a project failing to graduate to Integrated. Even though it hasn't happened yet, it will undoubtedly happen at some point in the future. We have a way for projects to leave incubation if they fail to become a strong emergent system, as described in option #2. Regards -steve Thanks Steven for the story. Based on your comments, I would change my vote to #2 as it sounds like the most practical approach. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Diversity as a requirement for incubation
Hi everyone, The TC meeting yesterday uncovered an interesting question which, so far, divided TC members. We require that projects have a number of different developers involved before they apply for incubation, mostly to raise the bus factor. But we also currently require some level of diversity in that development team: we tend to reject projects where all the development team comes from a single company. There are various reasons for that: we want to make sure the project survives the loss of interest of its main corporate sponsor, we want to make sure it takes into account more than just one company's use case, and we want to make sure there is convergence, collaboration and open development at play there, before we start spending common resources in helping them integrate with the rest of OpenStack. That said, it creates a chicken-and-egg issue: other companies are less likely to assign resources and converge to a project unless it gets blessed as THE future solution. And it's true that in the past a lot of projects really ramped up their communities AFTER being incubated. 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 ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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. 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. 2cts, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On Wed, Dec 18, 2013 at 11:40:21AM +0100, Thierry Carrez wrote: Hi everyone, The TC meeting yesterday uncovered an interesting question which, so far, divided TC members. We require that projects have a number of different developers involved before they apply for incubation, mostly to raise the bus factor. But we also currently require some level of diversity in that development team: we tend to reject projects where all the development team comes from a single company. There are various reasons for that: we want to make sure the project survives the loss of interest of its main corporate sponsor, we want to make sure it takes into account more than just one company's use case, and we want to make sure there is convergence, collaboration and open development at play there, before we start spending common resources in helping them integrate with the rest of OpenStack. That said, it creates a chicken-and-egg issue: other companies are less likely to assign resources and converge to a project unless it gets blessed as THE future solution. And it's true that in the past a lot of projects really ramped up their communities AFTER being incubated. 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 2 and 3 don't look all that different to me. Are you saying that 3 does not have any 'diversity' requirement for graduation ? Personally I'm leaning towards (3) at the moment. Thoughts ? Where is the current definition of the purpose of the Incubation process ? I found this page but it has a disclaimer saying it might be outdated, but the new page doesn't articulate any clear purpose https://wiki.openstack.org/wiki/Governance/Approved/Incubation Assuming for a minute the points from that page are still at least somewhat valid [quote] - Sustainable development processes - Growing the core development team - Establishing an initial user base - Maturing the software to an acceptable level of stability - Integration with OpenStack processes around testing, releases, and community management [/quote] Then my interpretation is that 'Growing the core development team' implicitly covers 'ensuring diversity'. As such I'd say option 2 is appropriate - no requirement for incubation, but mandate it for graduation. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
I think we're all happy that if a project *does* have a broad support base we're good; this is only the case for projects in one of two situations: - support is spread so thinly that each company involved in the area has elected to support a different solution - the project is just not that interesting to a wider audience It might be less about 'should we even allow its incubation' - yes, in exceptional circumstances we probably should, because it serves a useful purpose in that case of divided loyalties - but what checks should be in place to avoid problems of favouritism over technical merit, and of spreading our support thinly over areas of low demand. Neither of these things is directly a problem of diversity itself (e.g. the 'company gets bored'/'company goes tits up' problem); instead, the diversity serves as a warning flag indicating that decisions should not be taken lightly. -- Ian. On 18 December 2013 11:40, Thierry Carrez thie...@openstack.org wrote: Hi everyone, The TC meeting yesterday uncovered an interesting question which, so far, divided TC members. We require that projects have a number of different developers involved before they apply for incubation, mostly to raise the bus factor. But we also currently require some level of diversity in that development team: we tend to reject projects where all the development team comes from a single company. There are various reasons for that: we want to make sure the project survives the loss of interest of its main corporate sponsor, we want to make sure it takes into account more than just one company's use case, and we want to make sure there is convergence, collaboration and open development at play there, before we start spending common resources in helping them integrate with the rest of OpenStack. That said, it creates a chicken-and-egg issue: other companies are less likely to assign resources and converge to a project unless it gets blessed as THE future solution. And it's true that in the past a lot of projects really ramped up their communities AFTER being incubated. 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 ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
-Original Message- From: Sylvain Bauza [mailto:sylvain.ba...@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. 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. 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 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 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
Re: [openstack-dev] Diversity as a requirement for incubation
I would vote for the approach number 2. I think there are some distinct advantages for one company driving the development of a certain feature sets early in the life of the project, typically, the speed of development is faster, and it is easier to achieve focus early on. Allowing important initiatives to become incubated projects early will actually increase the speed of innovation and will encourage companies to tackle real problems sooner. Having said that, however, I believe that building sustainable communities is of paramount importance for the long term viability of OpenStack and its components. So, my preference would be to limit the incubation to let us say two cycles if a project failed to build a community. Alex Freedland Co-Founder and Chairman Mirantis, Inc. On Wed, Dec 18, 2013 at 2:40 AM, Thierry Carrez thie...@openstack.orgwrote: Hi everyone, The TC meeting yesterday uncovered an interesting question which, so far, divided TC members. We require that projects have a number of different developers involved before they apply for incubation, mostly to raise the bus factor. But we also currently require some level of diversity in that development team: we tend to reject projects where all the development team comes from a single company. There are various reasons for that: we want to make sure the project survives the loss of interest of its main corporate sponsor, we want to make sure it takes into account more than just one company's use case, and we want to make sure there is convergence, collaboration and open development at play there, before we start spending common resources in helping them integrate with the rest of OpenStack. That said, it creates a chicken-and-egg issue: other companies are less likely to assign resources and converge to a project unless it gets blessed as THE future solution. And it's true that in the past a lot of projects really ramped up their communities AFTER being incubated. 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 ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
Daniel P. Berrange wrote: On Wed, Dec 18, 2013 at 11:40:21AM +0100, Thierry Carrez wrote: 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 2 and 3 don't look all that different to me. Are you saying that 3 does not have any 'diversity' requirement for graduation ? They are very similar. In (3) we'd require that several independent parties have at least expressed interest in joining the project in the future, while in (2) we'd completely ignore diversity as a criteria for incubation and only evaluate it at graduation. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On Wed, Dec 18, 2013 at 6:04 AM, Sylvain Bauza sylvain.ba...@bull.netwrote: 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. 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. Being approved for incubation is not a guarantee that a project will graduate, and it's not sufficient to judge a project solely on technical criteria. In addition to having strong technical merit, new projects need to fit into the community socially by following common conventions for interaction and collaboration. The goal of raising the requirements for entering incubation and then graduating is to ensure that projects meet all of the community's standards (technical and social) by the time they graduate. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On Wed, Dec 18, 2013 at 6:18 AM, Daniel P. Berrange berra...@redhat.comwrote: On Wed, Dec 18, 2013 at 11:40:21AM +0100, Thierry Carrez wrote: Hi everyone, The TC meeting yesterday uncovered an interesting question which, so far, divided TC members. We require that projects have a number of different developers involved before they apply for incubation, mostly to raise the bus factor. But we also currently require some level of diversity in that development team: we tend to reject projects where all the development team comes from a single company. There are various reasons for that: we want to make sure the project survives the loss of interest of its main corporate sponsor, we want to make sure it takes into account more than just one company's use case, and we want to make sure there is convergence, collaboration and open development at play there, before we start spending common resources in helping them integrate with the rest of OpenStack. That said, it creates a chicken-and-egg issue: other companies are less likely to assign resources and converge to a project unless it gets blessed as THE future solution. And it's true that in the past a lot of projects really ramped up their communities AFTER being incubated. 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 2 and 3 don't look all that different to me. Are you saying that 3 does not have any 'diversity' requirement for graduation ? Personally I'm leaning towards (3) at the moment. Thoughts ? Where is the current definition of the purpose of the Incubation process ? I found this page but it has a disclaimer saying it might be outdated, but the new page doesn't articulate any clear purpose https://wiki.openstack.org/wiki/Governance/Approved/Incubation The most current approved list is at http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements(we're working on publishing those to a more readable format and updating wiki references). Doug Assuming for a minute the points from that page are still at least somewhat valid [quote] - Sustainable development processes - Growing the core development team - Establishing an initial user base - Maturing the software to an acceptable level of stability - Integration with OpenStack processes around testing, releases, and community management [/quote] Then my interpretation is that 'Growing the core development team' implicitly covers 'ensuring diversity'. As such I'd say option 2 is appropriate - no requirement for incubation, but mandate it for graduation. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/:| |: http://libvirt.org -o- http://virt-manager.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On Wed, Dec 18, 2013 at 8:06 AM, Jarret Raim jarret.r...@rackspace.comwrote: -Original Message- From: Sylvain Bauza [mailto:sylvain.ba...@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
Re: [openstack-dev] Diversity as a requirement for incubation
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
Re: [openstack-dev] Diversity as a requirement for incubation
On 12/18/2013 03:40 AM, Thierry Carrez wrote: Hi everyone, The TC meeting yesterday uncovered an interesting question which, so far, divided TC members. We require that projects have a number of different developers involved before they apply for incubation, mostly to raise the bus factor. But we also currently require some level of diversity in that development team: we tend to reject projects where all the development team comes from a single company. There are various reasons for that: we want to make sure the project survives the loss of interest of its main corporate sponsor, we want to make sure it takes into account more than just one company's use case, and we want to make sure there is convergence, collaboration and open development at play there, before we start spending common resources in helping them integrate with the rest of OpenStack. That said, it creates a chicken-and-egg issue: other companies are less likely to assign resources and converge to a project unless it gets blessed as THE future solution. And it's true that in the past a lot of projects really ramped up their communities AFTER being incubated. 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 I apparently posted on the prior thread regarding Barbican my experiences with Heat incubation. Option #2 is best. Managers at companies are much more willing to invest RD money into a project which is judged to atleast have a potential path to success. I think this is because at many companies Managers are judged in their reviews and compensated based upon how effectively they manage their people resources to achieve their goals. I spent countless hours on the phone in the early days of Heat trying to fulfill the unwritten diversity requirement that I forsaw being a potential problem for Heat to enter Incubation. In the end, I was completely unsuccessful at convincing any company to invest any people in an RD effort, even though Red Hat was all-in on OpenStack and the Heat eight person development team at Red Hat was all-in on Heat as well. In the end, I think the various managers at different companies I spoke to just couldn't justify it in their organization if Heat failed. This radically changed once we entered incubation. Suddenly a bunch of people from many companies were committing patches, doing reviews. Our IRC channel exploded with people. The small core team was bombarded with questions. This all happened because of the commitment the OpenStack TC made when we were incubated to indicate yes Heat is in OpenStack's scope, and yes we plan to support the project from an infrastructure perspective to make it successful, and yes, we think the implementation meets our community quality guidelines. I will grant that if this behavior doesn't happen after incubation, it should block integration, and maybe seen as an exit path out of incubation. 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 ? In the early days of incubation requests, I got the distinct impression managers at companies believed that actually getting a project incubated in OpenStack was not possible, even though it was sparsely documented as an option. Maybe things are different now that a few projects have actually run the gauntlet of incubation and proven that it can be done ;) (see ceilometer, heat as early examples). But I can tell you one thing for certain, an actual incubation commitment from the OpenStack Technical Committee has a huge impact - it says Yes we think this project has great potential for improving OpenStack's scope in a helpful useful way and we plan to support the program to make it happen. Without that commitment, managers at companies have a harder time justifying RD expenses. That is why I am not a big fan of approach #3 - companies are unlikely to commit without a commitment from the TC first ;-) (see chicken/egg in your original argument ;) We shouldn't be afraid of a project failing to graduate to Integrated. Even though it hasn't happened yet, it will undoubtedly happen at some point in the future. We have a way for projects to leave incubation if they fail to become a strong emergent system, as described in option #2. Regards -steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On 12/18/2013 10:37 AM, Steven Dake wrote: On 12/18/2013 03:40 AM, Thierry Carrez wrote: Hi everyone, The TC meeting yesterday uncovered an interesting question which, so far, divided TC members. We require that projects have a number of different developers involved before they apply for incubation, mostly to raise the bus factor. But we also currently require some level of diversity in that development team: we tend to reject projects where all the development team comes from a single company. There are various reasons for that: we want to make sure the project survives the loss of interest of its main corporate sponsor, we want to make sure it takes into account more than just one company's use case, and we want to make sure there is convergence, collaboration and open development at play there, before we start spending common resources in helping them integrate with the rest of OpenStack. That said, it creates a chicken-and-egg issue: other companies are less likely to assign resources and converge to a project unless it gets blessed as THE future solution. And it's true that in the past a lot of projects really ramped up their communities AFTER being incubated. 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 I apparently posted on the prior thread regarding Barbican my experiences with Heat incubation. Option #2 is best. Managers at companies are much more willing to invest RD money into a project which is judged to atleast have a potential path to success. I think this is because at many companies Managers are judged in their reviews and compensated based upon how effectively they manage their people resources to achieve their goals. I spent countless hours on the phone in the early days of Heat trying to fulfill the unwritten diversity requirement that I forsaw being a potential problem for Heat to enter Incubation. In the end, I was completely unsuccessful at convincing any company to invest any people in an RD effort, even though Red Hat was all-in on OpenStack and the Heat eight person development team at Red Hat was all-in on Heat as well. In the end, I think the various managers at different companies I spoke to just couldn't justify it in their organization if Heat failed. This radically changed once we entered incubation. Suddenly a bunch of people from many companies were committing patches, doing reviews. Our IRC channel exploded with people. The small core team was bombarded with questions. This all happened because of the commitment the OpenStack TC made when we were incubated to indicate yes Heat is in OpenStack's scope, and yes we plan to support the project from an infrastructure perspective to make it successful, and yes, we think the implementation meets our community quality guidelines. I will grant that if this behavior doesn't happen after incubation, it should block integration, and maybe seen as an exit path out of incubation. I think this is really good concrete feedback, and definitely puts me on the #2/3 path. 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 ? In the early days of incubation requests, I got the distinct impression managers at companies believed that actually getting a project incubated in OpenStack was not possible, even though it was sparsely documented as an option. Maybe things are different now that a few projects have actually run the gauntlet of incubation and proven that it can be done ;) (see ceilometer, heat as early examples). But I can tell you one thing for certain, an actual incubation commitment from the OpenStack Technical Committee has a huge impact - it says Yes we think this project has great potential for improving OpenStack's scope in a helpful useful way and we plan to support the program to make it happen. Without that commitment, managers at companies have a harder time justifying RD expenses. That is why I am not a big fan of approach #3 - companies are unlikely to commit without a commitment from the TC first ;-) (see chicken/egg in your original argument ;) We shouldn't be afraid of a project failing to graduate to Integrated. Even though it hasn't happened yet, it will undoubtedly happen at some point in the future. We have a way for projects to leave incubation if they fail to become a strong emergent system, as described in option #2. Agreed. One of the things I
Re: [openstack-dev] Diversity as a requirement for incubation
On 18/12/13 11:40 +0100, Thierry Carrez wrote: Hi everyone, The TC meeting yesterday uncovered an interesting question which, so far, divided TC members. We require that projects have a number of different developers involved before they apply for incubation, mostly to raise the bus factor. But we also currently require some level of diversity in that development team: we tend to reject projects where all the development team comes from a single company. There are various reasons for that: we want to make sure the project survives the loss of interest of its main corporate sponsor, we want to make sure it takes into account more than just one company's use case, and we want to make sure there is convergence, collaboration and open development at play there, before we start spending common resources in helping them integrate with the rest of OpenStack. That said, it creates a chicken-and-egg issue: other companies are less likely to assign resources and converge to a project unless it gets blessed as THE future solution. And it's true that in the past a lot of projects really ramped up their communities AFTER being incubated. 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 My vote goes for #3 Personally I'm leaning towards (3) at the moment. Thoughts ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco pgp1SYfXAXnZd.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On Wed, Dec 18, 2013 at 10:58 AM, Sean Dague s...@dague.net wrote: On 12/18/2013 10:37 AM, Steven Dake wrote: On 12/18/2013 03:40 AM, Thierry Carrez wrote: Hi everyone, The TC meeting yesterday uncovered an interesting question which, so far, divided TC members. We require that projects have a number of different developers involved before they apply for incubation, mostly to raise the bus factor. But we also currently require some level of diversity in that development team: we tend to reject projects where all the development team comes from a single company. There are various reasons for that: we want to make sure the project survives the loss of interest of its main corporate sponsor, we want to make sure it takes into account more than just one company's use case, and we want to make sure there is convergence, collaboration and open development at play there, before we start spending common resources in helping them integrate with the rest of OpenStack. That said, it creates a chicken-and-egg issue: other companies are less likely to assign resources and converge to a project unless it gets blessed as THE future solution. And it's true that in the past a lot of projects really ramped up their communities AFTER being incubated. 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 I apparently posted on the prior thread regarding Barbican my experiences with Heat incubation. Option #2 is best. Managers at companies are much more willing to invest RD money into a project which is judged to atleast have a potential path to success. I think this is because at many companies Managers are judged in their reviews and compensated based upon how effectively they manage their people resources to achieve their goals. I spent countless hours on the phone in the early days of Heat trying to fulfill the unwritten diversity requirement that I forsaw being a potential problem for Heat to enter Incubation. In the end, I was completely unsuccessful at convincing any company to invest any people in an RD effort, even though Red Hat was all-in on OpenStack and the Heat eight person development team at Red Hat was all-in on Heat as well. In the end, I think the various managers at different companies I spoke to just couldn't justify it in their organization if Heat failed. This radically changed once we entered incubation. Suddenly a bunch of people from many companies were committing patches, doing reviews. Our IRC channel exploded with people. The small core team was bombarded with questions. This all happened because of the commitment the OpenStack TC made when we were incubated to indicate yes Heat is in OpenStack's scope, and yes we plan to support the project from an infrastructure perspective to make it successful, and yes, we think the implementation meets our community quality guidelines. I will grant that if this behavior doesn't happen after incubation, it should block integration, and maybe seen as an exit path out of incubation. I think this is really good concrete feedback, and definitely puts me on the #2/3 path. 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 ? In the early days of incubation requests, I got the distinct impression managers at companies believed that actually getting a project incubated in OpenStack was not possible, even though it was sparsely documented as an option. Maybe things are different now that a few projects have actually run the gauntlet of incubation and proven that it can be done ;) (see ceilometer, heat as early examples). But I can tell you one thing for certain, an actual incubation commitment from the OpenStack Technical Committee has a huge impact - it says Yes we think this project has great potential for improving OpenStack's scope in a helpful useful way and we plan to support the program to make it happen. Without that commitment, managers at companies have a harder time justifying RD expenses. That is why I am not a big fan of approach #3 - companies are unlikely to commit without a commitment from the TC first ;-) (see chicken/egg in your original argument ;) We shouldn't be afraid of a project failing to graduate to Integrated. Even though it hasn't happened yet, it will undoubtedly happen at some point in the future. We
Re: [openstack-dev] Diversity as a requirement for incubation
On Wed, Dec 18, 2013 at 10:20 AM, Jarret Raim jarret.r...@rackspace.comwrote: 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 don't remember having that much trouble when we started ceilometer. What is the perceived risk of working on a project before it is accepted at some level? 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 We do this sort of risk assessment all the time. For internal projects at DreamHost (and I'm sure at other companies), we lower the risk by having more than one developer who understands the code. For OpenStack requirements, we look for a healthy and active development community supporting the library. Applying similar criteria to new OpenStack projects seems perfectly reasonable. More specifically, I would like to have the commitment to a potential new OpenStack project spread across more than one company. We've recently had IBM ask to withdraw a driver from nova because they changed directions internally. I wouldn't want a change in direction (or profitability, or whatever) in a single driving company behind a project cause it to fail. The question is when to put that diversity requirement in place. 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. Yes, hence this email thread. :-) 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? I have more of an issue with a project failing *after* becoming integrated than during incubation. That's why we have the incubation period to begin with. For the same reason, I'm leaning towards allowing projects into incubation without a very diverse team, as long as there is some recognition that they won't be able to graduate in that state, no matter the technical situation. 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? What data are you citing? We haven't done this very many times. Doug 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On 18/12/13 12:35 -0500, Doug Hellmann wrote: On Wed, Dec 18, 2013 at 10:58 AM, Sean Dague s...@dague.net wrote: On 12/18/2013 10:37 AM, Steven Dake wrote: But I can tell you one thing for certain, an actual incubation commitment from the OpenStack Technical Committee has a huge impact - it says Yes we think this project has great potential for improving OpenStack's scope in a helpful useful way and we plan to support the program to make it happen. Without that commitment, managers at companies have a harder time justifying RD expenses. That is why I am not a big fan of approach #3 - companies are unlikely to commit without a commitment from the TC first ;-) (see chicken/egg in your original argument ;) We shouldn't be afraid of a project failing to graduate to Integrated. Even though it hasn't happened yet, it will undoubtedly happen at some point in the future. We have a way for projects to leave incubation if they fail to become a strong emergent system, as described in option #2. Agreed. One of the things I think we are missing with the incubation project is checkpoints. We really should be reviewing incubated projects at the end of every cycle (and maybe at milestone-2 as an interim) and give them some feedback on how they are doing on integration requirements, or even how they are doing keeping up with what's needed for incubation (and de-incubate if required). +1 FWIW, Marconi's team sticks to OpenStack's milestones. As part of the incubation process, projects should start 'behaving' as they were integrated. This will teach the members of the team how the release cycle works and it'll also help the TC to review the work going on in the project based on the OpenStack milestones. Also, incubated projects can ask for reviews / support at anytime. Cheers, FF -- @flaper87 Flavio Percoco pgp80J9z8s_ZD.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On 12/18/2013 07:01 AM, Dolph Mathews wrote: Options 2 and 3 sound identical to me, when realistically applied. Option 3 just makes the common sense aspect mandatory. Indeed, Option 3 gets my vote. One aspect I'd like to mention regarding diversity of contributors in any open source project is a crucial element gives credibility to its open sourceness. Many of the tools that do software evaluation pay close attention to this element. 'Contributors' is to be intended in a wider term than just code developers or commits: having users very involved in design discussions or providing test/use cases, for example, would be IMHO evaluated positively towards a diversity score. Option 3 is a good balance because it helps projects get started and puts pressure on them to grow outside of the team that started. It's not a secret that the outside-looking aspect of OpenStack since its inception is what made it so successful so rapidly. One team coding, one team recruiting contributors (users and developers): let's keep the model going. /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On Wed, Dec 18, 2013 at 2:40 AM, Thierry Carrez thie...@openstack.orgwrote: 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 ? 3 gets my vote. As I've voiced over and over on the Barbican incubation thread, diversity is going to help the project gain contributors. You'll have a hard time gaining contributors if it's just one-sided designed solutions that only some companies can use. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Diversity as a requirement for incubation
On 12/18/2013 12:34 PM, Doug Hellmann wrote: I have more of an issue with a project failing *after* becoming integrated than during incubation. That's why we have the incubation period to begin with. For the same reason, I'm leaning towards allowing projects into incubation without a very diverse team, as long as there is some recognition that they won't be able to graduate in that state, no matter the technical situation. This precisely sums up my view as well. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
