[openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

Doug Hellmann doug at doughellmann.com
Mon Aug 25 19:06:12 UTC 2014


On Aug 23, 2014, at 6:35 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Dolph Mathews's message of 2014-08-22 09:45:37 -0700:
>> On Fri, Aug 22, 2014 at 11:32 AM, Zane Bitter <zbitter at redhat.com> wrote:
>> 
>>> On 22/08/14 11:19, Thierry Carrez wrote:
>>> 
>>>> Zane Bitter wrote:
>>>> 
>>>>> On 22/08/14 08:33, Thierry Carrez wrote:
>>>>> 
>>>>>> We also
>>>>>> still need someone to have the final say in case of deadlocked issues.
>>>>>> 
>>>>> 
>>>>> -1 we really don't.
>>>>> 
>>>> 
>>>> I know we disagree on that :)
>>>> 
>>> 
>>> No problem, you and I work in different programs so we can both get our
>>> way ;)
>>> 
>>> 
>>> People say we don't have that many deadlocks in OpenStack for which the
>>>>>> PTL ultimate power is needed, so we could get rid of them. I'd argue
>>>>>> that the main reason we don't have that many deadlocks in OpenStack is
>>>>>> precisely *because* we have a system to break them if they arise.
>>>>>> 
>>>>> 
>>>>> s/that many/any/ IME and I think that threatening to break a deadlock by
>>>>> fiat is just as bad as actually doing it. And by 'bad' I mean
>>>>> community-poisoningly, trust-destroyingly bad.
>>>>> 
>>>> 
>>>> I guess I've been active in too many dysfunctional free and open source
>>>> software projects -- I put a very high value on the ability to make a
>>>> final decision. Not being able to make a decision is about as
>>>> community-poisoning, and also results in inability to make any
>>>> significant change or decision.
>>>> 
>>> 
>>> 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.
>> 
> 
> Have we had many instances where a project's community divided into
> two camps and dug in to the point where they actually needed active
> moderation? And in those cases, was the PTL not already on one side of
> said argument? I'd prefer specific examples here.
> 
>>> 
>>> I have yet to see a deadlock in Heat that wasn't resolved by better
>>> communication.
>> 
>> 
>> Moderation == bettering communication. I'm under the impression that you
>> and Thierry are agreeing here, just from opposite ends of the same spectrum.
>> 
> 
> I agree as well. PTL is a servant of the community, as any good leader
> is. If the PTL feels they have to drop the hammer, or if an impass is
> reached where they are asked to, it is because they have failed to get
> everyone communicating effectively, not because "that's their job.”

That’s certainly how I approach it. I consider myself responsible for helping the team coordinate and making sure we have everything covered. Sometimes that means asking for volunteers for a new task, and sometimes it means a gentle reminder of an previous commitment.

That said, some responsibilities of the PTL role are outward-facing. Potentially anyone on the team could pick up those duties, just as any of the inward-facing duties, but having a single initial point of contact is especially useful when the priorities of two teams need to be aligned for a period of time to work on a joint task.

Doug

> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list