Open Stack

On 05/31/2013 08:06 AM, Sean Dague wrote:
> On 05/31/2013 07:49 AM, Monty Taylor wrote:
>>
>>
>> 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)
> 
> For that to be the case, one company would need to have ~300 active devs
> on OpenStack (which is at least a 6x increase from all the top
> contributing companies). If one organization is really contributing 1/2
> the labor force to the project, and no other organization(s) stepped up
> to share some of the burden, we've got much bigger issues than TC
> representation.

++

>> 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?
> 
> It feels like complexity here is the enemy of transparency. Is Monty a
> CI, TripleO, or oslo rep? It gets complicated quickly. Does mikal run as
> oslo vs. nova? And does he pick in advance because his chances are
> better in one than the other?

That's why I submitted a code version. I actually don't think it's that
complex if we do a single election without people pre-declaring. The
categories are for PTL representation - not project representation. So
far we have never had a person who is PTL of two projects (eek) I would
be a CI rep. In the case of "co-PTL's" it's really about looking at each
candidate in the results list one in turn, seeing if they are the PTL
(or co-PTL) for any of the categories still un-represented, and if not
putting them in the at-large pool. The only weird corner case is if a
category has no PTL's run at all, and that's the one where I was
suggesting that we then fill that category with the top voted core
member of any of that category's projects.

Piece of cake. :)

> It also feels to me like we're going to have to adjust categories every
> 6 months to a year to match the changing focus of the project, otherwise
> we encode in rules something which is better off letting the community
> just decide on over time.

Yeah- the categories themselves would need a bit of work. I don't think
we're likely to want to replace/change Compute, Network or Storage. I'm
pretty sure that "All the supporting infra/qa/ci/release/beer" will want
to be a category until the end of time. The other 2 or 3 categories, on
the other hand, seem both fluid and hard to define, I agree.

What if we made it 5 categories + 8 direct, and made the 5th category
"other"

> And if that's true... why not just give the flat 11 a shot. If it seems
> to work, cool. Super low maintenance, no bikeshedding on categories, no
> PTL growth concerns blocking things from getting incubated.
> 
> If not, in 6 months or a year we revisit. Which we'd have to do on any
> category based model anyway. If OpenStack has taught me anything, it's
> that predicting where OpenStack is going to be in a year is really hard.
> Encoding the future structure of the TC, based on a snapshot of what
> OpenStack seems to care about today, just seems doomed to unoptimal
> results.

Don't get me wrong - I'm fine with direct election - but it seems that
there might be a non-scary middle ground too.