Open Stack

On 01/15/2013 10:52 AM, Thierry Carrez wrote:
> Hi everyone,
>
> The OpenStack Technical Committee, representation of the technical
> contributors to the project, is currently composed of 13 members, the 8
> "core" projects PTLs and 5 directly-elected members.
>
> We are considering adding more projects in the integrated release in the
> future, but adding more PTLs with guaranteed TC seats doesn't really
> scale, quickly leading to committee bloat (personally I think 13 is the
> maximum workable number). There is even resistance to accepting new
> projects due to the fear of inefficiency in the TC, and fear of dilution
> of key TC members influence. That shouldn't be what drives our decisions
> on graduating from incubation.
>
> We should solve that before we consider the addition of new projects,
> and before we run the next TC elections. There are a number of ways to
> address that, and some of them were expressed at a recent TC meeting:
>
> 1/ Keep the same setup, but refrain from adding new projects
>
> 2/ Keep the same setup, but only have some PTLs have guaranteed seats
> (special-case some ("inner core") projects)
>
> 3/ Limit the TC to 13 members, and have them all directly-elected (the
> most significant PTLs will get elected anyway)
>
> 4/ Limit the TC to 13 members, have them all directly-elected, *and*
> guarantee that a minimum of 8 PTLs end up in the committee
>
> Thoughts ? Other potential solutions ?
>
> Personally, I think (1) is not a solution: we shouldn't limit what is
> part of the integrated release based on fear of committee bloat or
> influence dilution. (2) doesn't sound very fair (who gets to define
> which project should be special-cased) and doesn't prevent bloat (it
> only slows it down).
>
> I like (3) but I agree that there is a risk in Condorcet that people
> having horizontal functions will get overrepresented, and we'd end up
> with less PTLs (vertical functions) than we'd like. So I think (4) is a
> good middle ground: prevents bloat, accommodates further growth in a
> relatively-fair way while ensuring we get PTLs in the final committee.

Either 3 or 4 seem sane to me, though you might decide to adjust the 
minimum PTL count to 7. 8 was just what happened to be, no reason that 
it's a magic number. 7 is the minimum to ensure a PTL majority at a 13 
person TC, which I think is really the goal. I don't feel strongly about 
the 7 vs. 8 thing, just adding options to the discussion.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com