Open Stack

TL;DR: I'm against an all-elected TC, and moreover think that you can never properly represent an ever-growing, ever-changing community with a fixed-size elected body.

In any "democratic" process, one of the most crucial aspects is protecting the rights of minorities, and an all-elected TC is a regression from that. It's pretty clear that there are *big* projects and *small* projects, and we all know there are *big* companies and *small* companies. Well, an all-elected TC favors big companies and big projects by a landslide.

The current TC actually does a remarkably good job of considering the impact of its decisions on the "little guys", but that's partly because there's a an enforced representation of all projects/interests on the current TC. The all-PTLs-have-a-seat model ensures a better balance than free-for-all elections ever could. It forms a representative democracy by segmenting the voting population into elections per-project which roll up to form the body of the TC, somewhat like the US senate where each state gets two senators regardless of size. Even in the US House of Representatives, each state (project) is granted representation by its population. Nobody is left without a voice. And likewise there's no size cap. As the population grows, so does the number of representatives.

Long story short, I'm not seeing a breakdown of function with the current TC, and I'm not even close to convinced there will be one if it continues to grow. I see no benefit in the current proposal except perhaps to alleviate scheduling conflicts for a large group of people.

I'm open to other models of election, but I can't support a free-for-all. I think it will hurt us in the long run.

All the best,


-          Gabriel

From: Anne Gentle [mailto:anne at openstack.org]
Sent: Monday, January 28, 2013 11:06 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Motion on Technical Committee membership for Spring 2013 session



On Sat, Jan 26, 2013 at 5:48 PM, Monty Taylor <mordred at inaugust.com<mailto:mordred at inaugust.com>> wrote:


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?

Yes, this question is where I also see a disconnect between per-project-technical-committee-members and purpose-based technical committee members.

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?


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.

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.

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.
Anne

Monty

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130128/683698df/attachment.html>