Open Stack

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.


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.


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?


Thanks again,
Mark.