[openstack-dev] [governance] Becoming a Program, before applying for incubation

Russell Bryant rbryant at redhat.com
Fri Dec 13 15:44:58 UTC 2013


On 12/13/2013 10:37 AM, Flavio Percoco wrote:
> On 13/12/13 15:53 +0100, Thierry Carrez wrote:
>> Hi everyone,
>> 
>> TL;DR: Incubation is getting harder, why not ask efforts to apply
>> for a new program first to get the visibility they need to grow.
>> 
>> Long version:
>> 
>> Last cycle we introduced the concept of "Programs" to replace
>> the concept of "Official projects" which was no longer working
>> that well for us. This was recognizing the work of existing
>> teams, organized around a common mission, as an integral part of
>> "delivering OpenStack". Contributors to programs become ATCs, so
>> they get to vote in Technical Committee (TC) elections. In
>> return, those teams place themselves under the authority of the
>> TC.
>> 
>> This created an interesting corner case. Projects applying for 
>> incubation would actually request two concurrent things: be
>> considered a new "Program", and give "incubated" status to a code
>> repository under that program.
>> 
>> Over the last months we significantly raised the bar for
>> accepting new projects in incubation, learning from past
>> integration and QA mistakes. The end result is that a number of
>> promising projects applied for incubation but got rejected on
>> maturity, team size, team diversity, or current integration level
>> grounds.
>> 
>> At that point I called for some specific label, like "Emerging 
>> Technology" that the TC could grant to promising projects that
>> just need more visibility, more collaboration, more
>> crystallization before they can make good candidates to be made
>> part of our integrated releases.
>> 
>> However, at the last TC meeting it became apparent we could
>> leverage "Programs" to achieve the same result. Promising efforts
>> would first get their mission, scope and existing results blessed
>> and recognized as something we'd really like to see in OpenStack
>> one day. Then when they are ready, they could have one of their
>> deliveries apply for incubation if that makes sense.
>> 
>> The consequences would be that the effort would place itself
>> under the authority of the TC. Their contributors would be ATCs
>> and would vote in TC elections, even if their deliveries never
>> make it to incubation. They would get (some) space at Design
>> Summits. So it's not "free", we still need to be pretty
>> conservative about accepting them, but it's probably manageable.
>> 
>> I'm still weighing the consequences, but I think it's globally
>> nicer than introducing another status. As long as the TC feels
>> free to revoke Programs that do not deliver the expected results
>> (or that no longer make sense in the new world order) I think
>> this approach would be fine.
>> 
>> Comments, thoughts ?
>> 
> 
> 
> My first thought while reading this email was:
> 
> What happens if that "Emerging Technology" doesn't move forward?

Thierry addressed that at the very end of his message:

  As long as the TC feels free to revoke  Programs that do not deliver
  the expected results (or that no longer make sense in the new world
  order) I think this approach would be fine.

> Will a Program with actual projects exist? (I personally think
> this will create some confusion).
> 
> I guess the same thing would happen with incubated projects that
> never graduate to integrated. However, the probability this would
> happen are way lower. You also make a good point w.r.t ATCs and the
> rights to vote.
> 
> -1 from me. I'd be even in favor to not calling any Program
> official until there's an integrated *team* - not project - working
> on it. Notice that I'm using the term 'team' and not projects.
> Programs like 'Documentation' have an integrated team working on it
> and are part of every release cycle, the same thing applies for the
> "Release Cycle Management" program, etc.

We wouldn't create a program without an existing team doing some work
already.  We even have rules around now programs along side the rules
for incubating/graduating projects:

http://git.openstack.org/cgit/openstack/governance/tree/reference/new-programs-requirements

> With the above, I'm basically saying that a Queuing ;) program 
> shouldn't exist until there's an integrated team of folks working
> on queuing. Incubation doesn't guarantees integration and
> "emerging technology" doesn't guarantees incubation. Both stages
> mean there's interest about that technology and that we're looking
> forward to see it being part of OpenStack, period. Each stage
> probably means a bit more than that but, IMHO, that's the
> 'community' point of view of those stages.
> 
> What if we have a TC-managed* Program incubation period? The
> Program won't be managed by the team working on the emerging
> technology, nor the team working on the incubated project. Until
> those projects don't graduate, the program won't be official nor
> will have the 'rights' of other programs. And if the project fits
> into another program, then it won't be officially part of it until
> it graduates.
> 
> Unless I'm completely wrong about what a program is / should be,
> I'm leaning towards -1.
> 
> * I'm sorry, I couldn't come up with a better term for this. :)
> 
> Cheers, FF
> 
> 
> 
> 
> _______________________________________________ OpenStack-dev
> mailing list OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Russell Bryant



More information about the OpenStack-dev mailing list