Open Stack

On Tue, 2013-12-17 at 11:25 +0100, Thierry Carrez wrote:
> 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.

How about if we had an "emerging projects" page where the TC feedback on
each project would be listed?

That would give visibility to our feedback, without making it a yes/no
blessing. Ok, whether to list any feedback about the project on the page
is a yes/no decision, but at least it allows us to fully express why we
find the project promising, what people need to help with in order for
it to be incubated, etc.

With a formal yes/no status, I think we'd struggle with projects which
we're not quite ready to even bless with an "emerging" status but we
still want to encourage them - this allows us to bless a project as
"emerging" but be explicit about our level of support for it.

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

I'm not loving the idea of blessing a team more or less independently of
the project they're producing.

I'd tend to be more wary of blessing a program rather than a fledgling
project - if a couple of developers show up and want to be blessed as
the "lampshade program", then I'd feel we're placing an awful lot of
trust in them because we're making them responsible for everything
lampshade related in OpenStack. If instead we were just saying "we like
this lampshade project you're working on", then we leave room for that
project to grow or wither or be obsoleted by another group working on a
competing lampshade project.

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

Honestly, I struggle to care much about ATC status or those programs
which are associated with individual projects - the principles I care
about here are:

  (1) that we should be fairly permissive about granting ATC status and

  (2) programs allow us bless as official those efforts or teams who
      aren't primarily proposing a project which will go through
      incubation

So I'd tend towards creating a program when a project is accepted into
incubation.

> > 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 :)

Yeah, proposed here:

  https://review.openstack.org/62612

Mark.