<br><br><div class="gmail_quote">On Tue, Jan 15, 2013 at 8:10 AM, Sean Dague <span dir="ltr"><<a href="mailto:sdague@linux.vnet.ibm.com" target="_blank">sdague@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 01/15/2013 10:52 AM, Thierry Carrez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone,<br>
<br>
The OpenStack Technical Committee, representation of the technical<br>
contributors to the project, is currently composed of 13 members, the 8<br>
"core" projects PTLs and 5 directly-elected members.<br>
<br>
We are considering adding more projects in the integrated release in the<br>
future, but adding more PTLs with guaranteed TC seats doesn't really<br>
scale, quickly leading to committee bloat (personally I think 13 is the<br>
maximum workable number). There is even resistance to accepting new<br>
projects due to the fear of inefficiency in the TC, and fear of dilution<br>
of key TC members influence. That shouldn't be what drives our decisions<br>
on graduating from incubation.<br>
<br>
We should solve that before we consider the addition of new projects,<br>
and before we run the next TC elections. There are a number of ways to<br>
address that, and some of them were expressed at a recent TC meeting:<br>
<br>
1/ Keep the same setup, but refrain from adding new projects<br>
<br>
2/ Keep the same setup, but only have some PTLs have guaranteed seats<br>
(special-case some ("inner core") projects)<br>
<br>
3/ Limit the TC to 13 members, and have them all directly-elected (the<br>
most significant PTLs will get elected anyway)<br>
<br>
4/ Limit the TC to 13 members, have them all directly-elected, *and*<br>
guarantee that a minimum of 8 PTLs end up in the committee<br>
<br>
Thoughts ? Other potential solutions ?<br>
<br>
Personally, I think (1) is not a solution: we shouldn't limit what is<br>
part of the integrated release based on fear of committee bloat or<br>
influence dilution. (2) doesn't sound very fair (who gets to define<br>
which project should be special-cased) and doesn't prevent bloat (it<br>
only slows it down).<br>
<br>
I like (3) but I agree that there is a risk in Condorcet that people<br>
having horizontal functions will get overrepresented, and we'd end up<br>
with less PTLs (vertical functions) than we'd like. So I think (4) is a<br>
good middle ground: prevents bloat, accommodates further growth in a<br>
relatively-fair way while ensuring we get PTLs in the final committee.<br>
</blockquote>
<br></div></div>
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.</blockquote>
<div><br></div><div><br></div><div>+1</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
-Sean<br>
<br>
-- <br>
Sean Dague<br>
IBM Linux Technology Center<br>
email: <a href="mailto:sdague@linux.vnet.ibm.com" target="_blank">sdague@linux.vnet.ibm.com</a><br>
alt-email: <a href="mailto:sldague@us.ibm.com" target="_blank">sldague@us.ibm.com</a></font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br>