Open Stack

On 25/08/14 06:30, Thierry Carrez wrote:
> Zane Bitter wrote:
>> On 22/08/14 12:45, Dolph Mathews wrote:
>>>>> I'm all for getting a final decision, but a 'final' decision that
>>>> has been
>>>>> imposed from outside rather than internalised by the participants is...
>>>>> rarely final.
>>>>>
>>> The expectation of a PTL isn't to stomp around and make "final"
>>> decisions,
>>> it's to step in when necessary and help both sides find the best
>>> solution.
>>> To moderate.
>>
>> Oh sure, but that's not just the PTL's job. That's everyone's job. Don't
>> you think?
>>
>> I did that before I was the PTL and will continue to do it after I'm no
>> longer the PTL. And if anyone in the (especially) the core or wider Heat
>> team sees an opportunity to step in and moderate a disagreement I
>> certainly expect them to take it and not wait for me to step in.
>>
>> I'm not calling for no leadership here - I'm calling for leadership from
>> _everyone_, not just from one person who holds a particular role.
>
> I guess the difference between you and me is that I don't see having a
> PTL as preventing that moderation and leadership from everyone. I really
> see it as a safety valve in case things ever go badly wrong. I prefer
> that safety valve to be built into the project leadership, rather than
> at the TC level.
>
> Could you explain how having a PTL is preventing that "leadership from
> everyone" ? Did it prevent it in Heat ? Did having the PTL safety valve
> hurt you ?

I'd say we've done fairly well, but I would attribute that at least in 
part to the fact that we've treated the PTL as effectively the temporary 
"release management contact" more than the "guy who will resolve 
disputes for us". In other words, despite rather than because of the 
requirement to have a PTL.

I do think that having a PTL with no actual responsibilities runs the 
risk of having it be seen as a trophy rather than a service to the 
community. The good PTLs - which so far is all of them - are likely to 
respond by volunteering for just as many things as they were doing 
before, so that will tend to counteract the goal of preventing burnout.

> I'm open to the alternative solution (which would be for programs which
> are not interested in having a PTL to just not have one). But then if
> things go badly wrong, you require the TC to step in with threats of
> removal of OpenStack and/or to force an election/vote in the middle of
> the crisis. I'm really failing to see how that would result, in those
> hypothetical crisis scenarios, in a better outcome.

I don't think there are any good scenarios if you get to that crisis 
point. Imagine a scenario where the community is more or less evenly 
split and neither side is willing to back down even after seeking 
guidance from the TC, the PTL breaks the deadlock by fiat in lieu of 
consensus, followed by an unusually high number of spelling mistakes 
corrections in the source code, a single-issue election, potentially a 
reversal of the decision and possibly a fork that will force the TC to 
step in and choose a side. (Note: not choosing is also a choice.) That's 
pretty much an unmitigated disaster too.

Our goal must be to avoid reaching the crisis point, and it seems to me 
that it is actually helpful to make clear to projects that their choices 
are:
Option A: reach consensus
Option B: there is no Option B

cheers,
Zane.