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