<br><br><div class="gmail_quote">On 15 January 2013 16:52, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> 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><div><br>What would be the duration of an electee's appointment? While option 3 sounds "about right", we likely want to avoid possible electoral tsunamis.<br>
<br>Rgds,<br>Woj.<br> </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>
Thierry Carrez (ttx)<br>
Chair, OpenStack Technical Committee<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br>