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

Thierry Carrez thierry at openstack.org
Tue Dec 17 10:25:47 UTC 2013


Mark McLoughlin wrote:
> I'm not totally convinced we need such formality around the TC
> expressing its support for an early-stage program/project/effort/team.

This is a difficult balance.

You want to help a number of projects attract more contributors and
reach critical mass. For that, they want visibility, and one way to give
them that is a formal blessing. On the other hand, we want to encourage
the spontaneous creation of teams and projects and reduce formality in
the early stages as much as possible...

> 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.

I think that level of formality would not trigger enough visibility, so
we'd be back to square 1 with projects applying for incubation because
it's the only way to get the visibility they need to attract enough
contributors.

So I think we need some official label. It can be attached to the
project ("emerging technology"), or it can be attached to the team and
its mission ("incoming/wannabe/emerging program").

One benefit of applying it to the team is that the effort can then more
naturally graduate to become a full-fledged program when the project
gets incubated or integrated, without applying to "become a program".

> 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.

That's a fair remark. "Programs" come with some expectation of
durability and permanence, and using the same term might set
expectations wrong. If we settle for a team-attached label, we should
probably avoid using "program" in its name (and call it
"incoming/wannabe/emerging effort" or something).

> 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.

Ideally I'd like to address the case of the "programs created from an
incubated project" in the same governance change. With the expectation
of durable endorsement we'd like to see attached with "Programs", it may
make sense to *not* automatically create a program when a project gets
incubated, but rather when a project is finally integrated.

So two options here:

- Consider incubated as emerging, not create a program and not grant ATC
status

- Consider incubated as integrated, create a program and grant ATC status

> 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?

That's a bit orthogonal to this discussion, but +1 :)

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list