<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 15, 2013 at 9:52 AM, 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></blockquote><div><br></div><div><br></div><div>Is the number 8 significant now due to the number of projects we have? Why not an odd number, 7 or 9, to encourage consensus-building towards a majority?<br>

<br></div><div>More thinking on another potential solution. PTLs are project technical leads. We could add a lot of projects in the next two years and want to be sure they're represented. So, turning "project" around a bit, is there another role, such as a representative Technical Lead for multiple projects to go under some day? I'm thinking this way due to previous requests around establishing a "common libraries" coordinator, an API coordinator, etc. Here are some categories:<br>

<br></div><div>Storage <br></div><div>Computing <br></div><div>Networking <br></div><div>Monitoring <br></div><div>Operating<br></div><div>Packaging <br></div><div>Continuous Integration and Builds<br></div><div>Doc <br>
QA<br>
Integration Testing<br>API <br></div><div>UI/CLI (Dashboard/clients)<br></div><div><br></div><div>That's twelve, and I may not be including all the categories. Some do not have projects yet. There may be another category of "services on top of Computing" that I'm under-representing, thinking of Databases or Load Balancers or DNS that would rely on Compute to provide their service. How would we expand to include them? <br>

<br>I worry about under-representation of a category, happening just because there isn't a "project" that's well-known enough to have an elected representative. Then again, I can be swayed by "if they don't care enough to create a technical project the OpenStack way, why should we represent them on a TC?"<br>

<br>Would this type of committee be useful in representing the broad technical contributor community? <br><br></div><div>For elections, projects would be placed under a category and only those who contribute could vote for their representative.<br>

<br>Thoughts? <br>Anne<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<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></div></div>