Mark McLoughlin wrote:
> On Mon, 2012-02-20 at 11:32 -0800, Jesse Andrews wrote:
>>
>> Perhaps it would be useful to share the the problems / issues you are
>> trying to improve. My reading is that TC = PBB 2.0
>>
>> * without appointed seats (PTLs or RAX appointed)
>> * attendance requirements
>
> Same reading here, but also:
>
> * emphasis on wider discussion before TC level voting
It is my attempt to translate what the proposed Structure document says
about the TC (no appointed seats, no automatic PTL seats) into a set of
more precise bylaws we can use.
Your analysis of PPB 2.0 is correct, though it also misses:
* Static number of seats (no committee bloat)
>> I'm particularly worried about the idea that PTLs aren't automatic.
I think that's necessary. As we split projects into more manageable and
engaging parts, the current system doesn't scale. What's the point of
voting if the Melange PTL has the same impact as the Nova PTL (no
offense meant). If you split Nova-volume out of Nova, you suddenly
create a new seat ?
As I say in the document, the PTLs are still very much part of the
discussion and can certainly influence the decisions. But when it comes
down to a vote, only the 9 elected people cast their vote. That's fair
and balanced.
>> What does it mean to allow decisions to made by the TC that a project
>> technical lead aren't inherently part of?
>
> Good question - e.g. if the TC votes that all projects should adopt the
> AwesomeDb library as a replacement for sqlalchemy and the PTL (and
> perhaps $project-core) disagrees, what then?
I don't think it's very different from the case where PPB 1.0 decides on
something that a given PTL disagrees with. The PTL voices his opinion,
tries to convince enough voting members, but may fail in doing so. The
fact that he himself is or is not voting is almost orthogonal to this.
> I think the answer to that is that the TC is not so much responsible for
> making a final call where there is two fundamentally opposing views, but
> rather it is responsible for building a rough consensus. TC voting
> should perhaps be about whether the TC think a rough consensus has been
> reached on a given topic.
>
> A PTL vehemently opposed to a given proposal is a signal that more work
> is needed. If the PTL is on the TC and a majority of the TC members vote
> against the PTL, that doesn't mean a consensus has been reached.
>
> A PTL has a strong veto power irrespective of his ability to vote on the
> TC. Also, $project-core members have somewhat of a veto power with the
> ability to -2 a review.
>
> IMHO, this is all very healthy. We don't want the TC to be a group of
> individuals making far reaching decisions without building a rough
> consensus between the main players.
The power is ultimately in the hands of the developers. My guess is that
the situation will not happen, but here are the checks and balances: The
PTL still decides what his project will ultimately do. Developers of the
project can elect a new PTL or fork. And in case of repeated and
unsolvable problems, the TC can decide to remove the "core" status of a
project if the way a given project wants to go and the way "OpenStack"
wants to go are not reconcilable.
--
Thierry Carrez (ttx)
Release Manager, OpenStack