<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 26, 2013 at 5:48 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.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="im"><br>
<br>
On 01/27/2013 04:28 AM, Mark McLoughlin wrote:<br>
> On Thu, 2013-01-24 at 17:44 +0100, Thierry Carrez wrote:<br>
><br>
>> The PTL is much more influential than a TC member. The PTL has ultimate<br>
>> (and *unshared*) say on what happens over his project. He takes precise<br>
>> day-to-day technical decisions, and can do all by himself.<br>
>><br>
>> Comparing that to just one vote on a committee of 13 members that<br>
>> address cross-project issues and express their opinion on a handful of<br>
>> issues every 6 months... I'm pretty sure it's clear what position ends<br>
>> up being more influential.<br>
><br>
> This is a pretty crucial point, I think.<br>
><br>
> I find it really, really sad that people could think that any project's<br>
> interests would be ignored if their PTL doesn't have a vote on the TC.<br>
<br>
</div>I agree - I think this is the important point.<br>
<br>
In fact, in areas where a decision by the TC had a clear dissent that<br>
directly affected one of the projects, that dissent has been accounted<br>
for (see the swift-exception to the release model)<br>
<br>
It turns out we all want the entire project, and each of its<br>
sub-projects individually to be really good.<br>
<div class="im"><br>
> We place far too much emphasis on voting in the Technical Committee. The<br>
> TC should instead be about building cross-project consensus. Close-run<br>
> votes on any matter is not a healthy basis to proceed with anything. The<br>
> fact that TC members have the option of voting against something without<br>
> blocking it means that members can avoid the responsibility of engaging<br>
> with the rest of the TC to find a consensus position that works for<br>
> them.<br>
<br>
</div>Totally agree. I never want to use a vote on the TC as a way to force<br>
people to bend to my will. At times it's the easiest forum to get<br>
attention for a thing that needs some consensus - and a vote on a thing<br>
can get someone to speak up in opposition that might otherwise have not<br>
been heard. Other than that - I much prefer less-active cycles for the<br>
TC than more.<br>
<div class="im"><br>
> Switching to an all-elected committee would give us the opportunity to<br>
> show that the consensus building model can work. Because an all-elected<br>
> TC that doesn't work to build consensus which involves all PTLs just<br>
> will not work.<br>
<br>
</div>Agree again.<br>
<div class="im"><br>
> Keeping the status quo and adding more PTLs will mean more PTLs fearful<br>
> of their project being ignored by an all-elected TC - i.e. I'm skeptical<br>
> we'll ever be brave enough to give all-elected a shot if we decide not<br>
> to now.<br>
<br>
</div>I'm in favor of all-elected TC. If the motion is presented, I will vote<br>
for it. I also won't die without one.<br>
<br>
My main concern, however it's addressed, is that project inclusion and<br>
make up can be an issue of technical design, not one that's tied to<br>
concerns about making a governance body have too many people.<br>
<br>
I'm not sure that the direct-election and the categories approaches are<br>
even necessarily at odds. What if we direct-elect TC members, institute<br>
categories and then have a PTL per-category instead of per-project?<br>
<br>
I bring that up because we already have categories. One is called Nova<br>
and it includes the project nova and the project python-novaclient.<br>
Moving forward - there were discussions at the last summit about whether<br>
or not LBaaS and DNSaaS should be separate projects or part of quantum.<br>
What if they were both "part of quantum" - but lived as separate code<br>
bases in separate repos? Why would splitting code into two different git<br>
repos _necessarily_ have anything to do with leadership of the code base?<br>
<br></blockquote><div><br></div>Yes, this question is where I also see a disconnect between per-project-technical-committee-members and purpose-based technical committee members. <br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For that matter, does anyone other than me think it's weird that nobody<br>
thinks that the TC needs to weigh in on Quantum adding DNS and<br>
Load-balancing as features, yet we _do_ think the TC needs to get<br>
involved if someone thinks those features should be added but want to do<br>
it in a separate git repository?<br>
<br></blockquote><div><br></div><div>Yes, the definition of projects based on code bases which are really features has always struck me as strange -- mostly from the perspective of "who's the technical leader who also understands the varied audiences" when I have docs questions. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we move to an all-elected TC right now, we've split the issue of PTLs<br>
from the issue of project structure. That should give us the space and<br>
freedom to ACTUALLY think about how project categories and organization<br>
might be better arranged. Then, whether we keep our current PTL model,<br>
or we develop some other self-organization strategy that we feel like<br>
we'd like more directly reflected in the TC structure, it probably<br>
wouldn't be crazy to get the all-elected TC to change to another model.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Thanks for summarizing all this Monty, I think you've been able to state more clearly what I've been trying to uncover in my emails. I also think that the incubation work will help us think clearly about defining the makeup of the TC so I'm glad to delay a motion to gather more info and input.<br>
<br></div><div>Anne<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">
Monty<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>