Open Stack

On 3/3/20 9:44 AM, Jean-Philippe Evrard wrote:
>> Off hand, I feel like my initial mental response was "Noooo!". Upon
>> thinking of this and talking to Mohammed some, I think it is a
>> necessary evolutionary step.  As a burned out PTL who cares, I wonder
>> "who will step up after me" and carry what I perceive as the
>> organizational and co-ordination overhead, standing on stage, and
>> running meetings. Nothing prevents any contributor from running a
>> community meeting, standing on a stage and giving a talk or project
>> update! We are a community, and single points of contact just lead
>> community members to burnout.
>>
>> Possibly what we are lacking is a "Time for a meeting!" bot.
>>
> 
> I am not sure to understand what you are proposing.
> 
> Wasn't the liaison's system meant for avoiding burnout by delegating
> tasks, while staying clear on duties? It avoids the back and forth of
> communication to some maintainer, solving the question "who is handling
> that?". It still allows delegation. IMO, there was never a limitation
> of the amount of liaisons for a single "kind" of liaison. You could
> have 2 ppl working on the releases, 2 on the bugs, etc.

Yeah, I always saw the liaison system as a way to spread the PTL 
workload, not as something to increase it. It was also a way to 
distribute work across the team without falling prey to the "someone 
else will do it" problem because you still have specific people assigned 
to specific tasks. I see the Neutron bug deputy and Keystone L1 
positions similarly, and I think they're good things.

As to whether all of the liaisons are still needed, I will admit there 
are only a handful of projects that really still have Oslo liaisons. I'm 
not sure eliminating it entirely benefits anyone though, it just means 
now I have to ping the PTL when I need to coordinate something with a 
project. Or if we eliminate the PTL then I have to throw issues into the 
IRC void and hope someone responds. When we have cross-project changes 
that involve a lot of projects that means inevitably someone won't 
respond and we have to start delivering ultimatums. Maybe that's okay, 
but it slows things down (we have to wait for a response, even if we 
don't get one) and always feels kind of unfriendly.

I guess what I'm saying is that eliminating the liaison position doesn't 
mean we stop needing a point of contact from a project. I suspect the 
same thing applies to the release team.

> 
> Don't get me wrong: on the "drop of the PTL" story, I was more in the
> "we should drop this" clan. When I discussed it last time with Mohammed
> (and others, but it was loooooong ago), I didn't focus on the liaisons.
> But before side-tracking this thread, I would like to understand what
> are the pain points in the current model (explicitly! examples!), and
> how moving away from PTLs and liaisons will help the team of
> maintainers. At first sight, it looks like team duties will be vague.
> There are various levels of success on self-organizing teams.

I've been skeptical of this before and I won't reiterate all of those 
arguments again unless it proves necessary, but I'm also curious what 
this would solve that PTL delegation can't already. Is it just a 
perception thing? Maybe we re-brand the PTL position "Project Delegator" 
or something to make it clear to potential candidates that they don't 
have to be responsible for everything that goes on in a project?

Unless we feel there are things PTLs are doing that don't need to be 
done, in which case we should clearly stop doing those things, the 
workload remains the same no matter what we call it, "maintainers" or 
"PTL and liaisons".

> 
> 
> Regards,
> JP
> 
>