Open Stack

On Tue, Jan 15, 2013 at 8:10 AM, Sean Dague <sdague at linux.vnet.ibm.com>wrote:

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



+1



>
>
>         -Sean
>
> --
> Sean Dague
> IBM Linux Technology Center
> email: sdague at linux.vnet.ibm.com
> alt-email: sldague at us.ibm.com
>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130115/1f2f8e79/attachment.html>