[openstack-dev] TC membership evolution, take 2

Monty Taylor mordred at inaugust.com
Fri May 31 11:49:28 UTC 2013



On 05/31/2013 06:21 AM, Thierry Carrez wrote:
> John Dickinson wrote:
>> As a smaller category list:
>>
>> Compute (eg Nova, Glance)
>> Storage (eg Swift, Cinder)
>> Networking (eg mutnauQ)
>> CI/QA/Docs (eg CI, tempest, docs)
>> Operations (eg Horizon, Heat, Ceilometer)
>> "cross project" (eg oslo, keystone)
>>
>> This certainly isn't a perfect list, but it's an alternative that has some strengths. [...]
> 
> The main issue I see with the "category" model (whatever the precise
> list is) is that it freezes the relationship between projects and the
> relative weight of their representation. Your list for example sets in
> stone the following statements: "Storage is as important as Compute",
> "Release management or vulnerability management should never be
> represented in the TC" and "most future projects will not get their own
> seats but will have to share the Operations seat(s)".
> 
> The risk is to grow a Technical Committee that is not representative of
> the body of current OpenStack contributors. You could argue that we
> don't care and that "the list" is how we want to freeze influence of
> each category into the TC forever... But having an oversight body that
> is no longer seen as representative of the body of contributors is how
> most projects end up having a fork to change their governance.
> 
> I've seen that happening in other projects I've been involved with...
> and personally I think we should make our best to prevent that from
> happening. This is why I favor more "representative" models like the
> "Best 7 PTLs + 6" or the "All-directly-elected 11" models.

Honestly, I think John's list isn't bad (it's not perfect, and it never
will be - why are docs and CI in one? on the other hand, why not? meh...)

I think what it points out to me is that what I want is:

Some amount of direct representation - because populist democracy is good
Some amount of categorical representation - because populist democracy
is bad


So I'm in favor of either the "Base 7 PTLs + 6 direct" but ... what if
we combine the two and have a rep from each of a set of categories
(similar to John's category list) and then a set of direct.

The point of the categories isn't to make the TC rep for the category an
über-PTL for the projects under it - it's to ensure that:

a) Nova doesn't get all the seats
b) It's harder for a single company to buy the TC by employing a bunch
of devs (if they do, they'll have to buy enough devs that they are
providing adequate coverage in all of the categories - so good on them)

How about:

Compute (eg Nova, Glance)
Storage (eg Swift, Cinder)
Networking (eg mutnauQ)
CI/QA/Docs/Release (eg CI, tempest, docs)
Operations (eg Horizon, Heat, Ceilometer, TripleO)
Cross Project (eg oslo, keystone, reddwarf)

+ 7 directly elected?

Then just do a single election with everyone running as individual
members, and when we're filling out winners, start with the top vote
getter, see if they are the PTL for any of the projects or programs, if
so, that person fills the requirement that we have a PTL from that
category. Then, for each person down the list, if their category is
already represented, then they become an at-large seat. If all the
at-large seats are filled but the categories are not, then we keep going
down the list of results until we find the top vote getting person who
fulfills the requirement that we have representation from that category.

Or, since we're technical:

slots = dict(
    compute=None,
    storage=None,
    networking=None,
    infra=None,
    ops=None,
    cross=None)
at_large = list()

for candidate in election_results_sorted_by_rank:
    ptl = candidate.get_ptl_category()
    if not slots[ptl]:
        slots[ptl] = candidate
        continue
    if len(at_large) < 7:
        at_large.append(candidate)
        continue

There is, of course, a bug in this in that it is technically possible
that nobody from any of the projects in a category runs. In that case,
I'd suggest that the top ranked core member from a project in that
category take the category slot. It's probably unlikely to come up.

Code review welcome :)



More information about the OpenStack-dev mailing list