[openstack-dev] Motion on Technical Committee membership for Spring 2013 session

Monty Taylor mordred at inaugust.com
Sat Jan 26 23:48:41 UTC 2013

On 01/27/2013 04:28 AM, Mark McLoughlin wrote:
> On Thu, 2013-01-24 at 17:44 +0100, Thierry Carrez wrote:
>> The PTL is much more influential than a TC member. The PTL has ultimate
>> (and *unshared*) say on what happens over his project. He takes precise
>> day-to-day technical decisions, and can do all by himself.
>> Comparing that to just one vote on a committee of 13 members that
>> address cross-project issues and express their opinion on a handful of
>> issues every 6 months... I'm pretty sure it's clear what position ends
>> up being more influential.
> This is a pretty crucial point, I think.
> I find it really, really sad that people could think that any project's
> interests would be ignored if their PTL doesn't have a vote on the TC.

I agree - I think this is the important point.

In fact, in areas where a decision by the TC had a clear dissent that
directly affected one of the projects, that dissent has been accounted
for (see the swift-exception to the release model)

It turns out we all want the entire project, and each of its
sub-projects individually to be really good.

> We place far too much emphasis on voting in the Technical Committee. The
> TC should instead be about building cross-project consensus. Close-run
> votes on any matter is not a healthy basis to proceed with anything. The
> fact that TC members have the option of voting against something without
> blocking it means that members can avoid the responsibility of engaging
> with the rest of the TC to find a consensus position that works for
> them.

Totally agree. I never want to use a vote on the TC as a way to force
people to bend to my will. At times it's the easiest forum to get
attention for a thing that needs some consensus - and a vote on a thing
can get someone to speak up in opposition that might otherwise have not
been heard. Other than that - I much prefer less-active cycles for the
TC than more.

> Switching to an all-elected committee would give us the opportunity to
> show that the consensus building model can work. Because an all-elected
> TC that doesn't work to build consensus which involves all PTLs just
> will not work.

Agree again.

> Keeping the status quo and adding more PTLs will mean more PTLs fearful
> of their project being ignored by an all-elected TC - i.e. I'm skeptical
> we'll ever be brave enough to give all-elected a shot if we decide not
> to now.

I'm in favor of all-elected TC. If the motion is presented, I will vote
for it. I also won't die without one.

My main concern, however it's addressed, is that project inclusion and
make up can be an issue of technical design, not one that's tied to
concerns about making a governance body have too many people.

I'm not sure that the direct-election and the categories approaches are
even necessarily at odds. What if we direct-elect TC members, institute
categories and then have a PTL per-category instead of per-project?

I bring that up because we already have categories. One is called Nova
and it includes the project nova and the project python-novaclient.
Moving forward - there were discussions at the last summit about whether
or not LBaaS and DNSaaS should be separate projects or part of quantum.
What if they were both "part of quantum" - but lived as separate code
bases in separate repos? Why would splitting code into two different git
repos _necessarily_ have anything to do with leadership of the code base?

For that matter, does anyone other than me think it's weird that nobody
thinks that the TC needs to weigh in on Quantum adding DNS and
Load-balancing as features, yet we _do_ think the TC needs to get
involved if someone thinks those features should be added but want to do
it in a separate git repository?

If we move to an all-elected TC right now, we've split the issue of PTLs
from the issue of project structure. That should give us the space and
freedom to ACTUALLY think about how project categories and organization
might be better arranged. Then, whether we keep our current PTL model,
or we develop some other self-organization strategy that we feel like
we'd like more directly reflected in the TC structure, it probably
wouldn't be crazy to get the all-elected TC to change to another model.


More information about the OpenStack-dev mailing list