Open Stack

Jay Pipes wrote:
> I don't believe the Programs are needed, as they are currently
> structured. I don't really believe they serve any good purposes, and
> actually serve to solidify positions of power, slanted towards existing
> power centers, which is antithetical to a meritocratic community.

Let me translate that, considering programs are just teams of people...
You're still OK with the concept of teams of people working toward a
common goal, but you don't think "blessing" some teams serves any good
purpose. Is that right? (if yes, see below for more on what that
actually means).

> [...]
>> If we want to follow your model, we probably would have to dissolve
>> programs as they stand right now, and have blessed categories on one
>> side, and teams on the other (with projects from some teams being
>> blessed as the current solution).
> 
> Why do we have to have "blessed" categories at all? I'd like to think of
> a day when the TC isn't picking winners or losers at all. Level the
> playing field and let the quality of the projects themselves determine
> the winner in the space. Stop the incubation and graduation madness and
> change the role of the TC to instead play an advisory role to upcoming
> (and existing!) projects on the best ways to integrate with other
> OpenStack projects, if integration is something that is natural for the
> project to work towards.

I'm still trying to wrap my head around what you actually propose here.
Do you just want to get rid of incubation ? Or do you want to get rid of
the whole "integrated release" concept ? The idea that we collectively
apply effort around a limited set of projects to make sure they are
delivered in an acceptable fashion (on a predictable schedule, following
roughly the same rules, with some amount of integrated feature, some
amount of test coverage, some amount of documentation...)

Because I still think there is a whole lot of value in that. I don't
think our mission is to be the sourceforge of cloud projects. Our
mission is to *produce* the ubiquitous Open Source Cloud Computing
platform. There must be some amount of opinionated choices there.

Everything else in our structure derives from that. If we have an
integrated release, we need to bless a set of projects that will be part
of it (graduation). We need to single out promising projects so that we
mentor them on the common rules they will have to follow there (incubation).

Now there are bad side-effects we need to solve, like the idea that
incubation and integration are steps on a openstack ecosystem holy
ladder that every project should aspire to climb.

>> That would leave the horizontal programs like Docs, QA or Infra,
>> where the team and the category are the same thing, as outliers again
>> (like they were before we did programs).
> 
> What is the purpose of having these programs, though? If it's just to
> have a PTL, then I think we need to reconsider the whole concept of
> Programs. [...]

The main purpose of programs (or "official teams") is that being part of
one of them gives you the right to participate in electing the Technical
Committee, and as a result places you under its authority. Both parties
have to agree to be placed under that contract, which is why teams have
to apply (we can't force them), and the TC has to accept (they can't
force us).

Programs have *nothing* to do with PTLs, which are just a convenient way
to solve potential decision deadlocks in teams (insert your favorite
dysfunctional free software project example here). We could get rid of
the PTL concept (to replace them for example with a set of designated
liaisons) and we would still have programs (teams) and projects (the
code repos that team is working on).

-- 
Thierry Carrez (ttx)