Open Stack

On 16/12/13 23:49 +0000, Mark McLoughlin wrote:
>Hi Thierry,
>
>On Fri, 2013-12-13 at 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 ?
>
>Thanks for writing this up; a few thoughts ...
>
>
>I'm not totally convinced we need such formality around the TC
>expressing its support for an early-stage program/project/effort/team.
>
>How about if we had an RFC process (hmm, but not in the IETF sense)
>whereby an individual or team can submit a document expressing a
>position and ask the TC to give its feedback? We would record that
>feedback in the governance repo, and it would be a short piece of prose
>(perhaps even recording a diversity of views amongst the TC members)
>rather than a yes/no status vote.
>
>In the case of a fledgling project, they'd write up something like a
>first draft of an incubation application and we'd give our feedback,
>encouragement, whatever.

This sounds reasonable. It also sounds like a good way to officially
put a TC stamp on an emerging technology before the request for
incubation. The benefits I see from this is that:

    1. The team working on that project knows there's an interest on
    the work they're doing and that the project fits into OpenStack

    2. They don't have to worry about what program the project fits
    in, yet. Instead, the team can focus on working towards
    incubation.

    3. The TC will be aware of this emerging technology. Emerging
    technologies could request 'follow-up' meetings to the TC, or the
    other way around. (Brainstorming)

I still think that emerging / incubated projects shouldn't worry about
programs. If they've been tagged as emerging or entered into
incubation is because the TC thinks they fit into OpenStack and that
should be enough until the project is ready to graduate.

>Setting a very low bar for the officialness of becoming a Program seems
>wrong to me - I wouldn't like to see Programs being added and then later
>removed with any sort of regularity. Part of what people are looking for
>is an indication of what's coming down the track and the endorsement
>implicit in becoming a Program - before a long-term viable team has been
>established - seems too strong for me.
>
>
>Even though this doesn't grant ATC status to the people working on those
>projects, I'm struggling to see that as a burning issue for anyone -
>honestly, if you're working on an early-stage, keen-to-be-incubated
>project then I'd be surprised if you didn't find some small way to
>contribute to one of our many ATC-granting projects.

+1 I agree here. One of the requirements for entering incubation is
being integrated with some of the OpenStack tools. Encouraging those
emerging teams to contribute to the tools they're using is the way to
go, IMHO.

>
>
>One thing I'm noticing that's missing from these new docs:
>
>  http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements
>  http://git.openstack.org/cgit/openstack/governance/tree/reference/new-programs-requirements
>
>is any caution around increasing the scope of OpenStack. I think we are
>cautious about this, but we haven't mentioned it beyond e.g.
>
>  ** Project must have a clear and defined scope
>  ** Project should not inadvertently duplicate functionality present in other
>     OpenStack projects. If they do, they should have a clear plan and timeframe
>     to prevent long-term scope duplication.
>  ** Project should leverage existing functionality in other OpenStack projects
>     as much as possible
>
>How would something like:
>
>  ** Project must have a clear and defined scope which, in turn, represents
>     a measured and obvious progression for OpenStack as a whole
>
>sound?

+1

Cheers,
FF

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131217/38c23173/attachment.pgp>