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

Thierry Carrez thierry at openstack.org
Tue Jan 29 10:24:19 UTC 2013


Gabriel Hurley wrote:
> 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.

This analogy is quite limited. First, even in the case of the House of
Representatives, there is a size cap (435). Each state gets a number of
seats corresponding to its share of the aggregate population of the 50
states. Second, adding states is not really a routine procedure, while
we are adding new projects almost every 6 months. Third, everyone only
belongs to one state at a time, while most developers participate (and
therefore vote) in multiple projects.

The current system is not very fair because some people's vote gets more
weight than others. Anne, working only on docs projects, gets one vote
in the directly-elected seats election. Another developer who touched
Horizon, Keystone and the Glance python client over the last year gets
four votes: one for the Horizon seat, one for the Keystone seat, one for
the Glance seat *and* one for the directly-elected seats. Nobody's vote
should be 4 times more important than someone else's.

One way to fix this fairness issue is to give everyone only one vote,
and to have a single election. I agree we need to avoid the "only big
projects represented" issue, but there are election systems that allow
that. In particular there are proportional options in Condorcet or STV
that can be used to ensure that 60% of the voters can't steal 100% of
the seats, and their collective influence be limited to 60% of the seats.

But this is not a house of representatives. It's a technical committee:
a small group of people elected to make technical calls when they are
needed. We need to accept not giving every subgroup a presence and a
vote, to keep the committee working and efficient. At the end of the
day, we need to be able to meet online, discuss and try to reach
consensus. That's possible in a group of 9-13. That's getting more
difficult with a group of 15-435. I don't really want us to have to meet
in person to come to decisions. I don't want our meetings to last 7
hours. I don't want us to meet just to vote.

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

The current proposal was withdrawn, so we should have plenty of time to
discuss a good compromise between committee size, representation of the
different technical aspects of the project and vote fairness.

-- 
Thierry Carrez (ttx)
Chair, OpenStack Technical Committee



More information about the OpenStack-dev mailing list