[all][tc] Moving PTL role to "Maintainers"
zbitter at redhat.com
Wed Mar 4 18:57:38 UTC 2020
On 2/03/20 4:45 pm, Mohammed Naser wrote:
> Hi everyone:
> We're now in a spot where we have an increasing amount of projects
> that don't end up with a volunteer as PTL, even if the project has
> contributors .. no one wants to hold that responsibility alone for
> many reasons. With time, the PTL role has become far more overloaded
> with many extra responsibilities than what we define in our charter:
> I think it's time to re-evaluate the project leadership model that we
> have. I am thinking that perhaps it would make a lot of sense to move
> from a single PTL model to multiple maintainers. This would leave it
> up to the maintainers to decide how they want to sort the different
> requirements/liaisons/contact persons between them.
Just for fun I had a read through the thread from when I last proposed
getting rid of PTLs, 5.5 years ago:
I wrote that when I was a PTL. Now that I have been on all sides of it
(Core team member, PTL, ex-PTL, TC member), let's see how well this has
> First off, the PTL is not responsible for everything in a project.
> *Everyone* is responsible for everything in a project.
> The PTL is *accountable* for everything in a project. PTLs are the
> mechanism the TC uses to ensure that programs remain accountable to the
> wider community.
I still think this is true. But it's also true that if everyone is
responsible then nobody is really responsible. Somebody has to be
responsible for knowing all of the things that somebody needs to be
responsible for and making sure that somebody is responsible for each.
That can be done without a PTL as such, but the PTL system does provide
a way of externally bootstrapping it in every project.
> We have a heavyweight election process for PTLs once every
> cycle because that used to be the process for electing the TC. Now that
> it no longer serves this dual purpose, PTL elections have outlived their
I had completely forgotten about this.
From a TC perspective, we don't have a lot of visibility on internal
ructions that may be going on in any particular project. The election
does at least assure us that there is an outlet valve for any issues,
and the fact that it is completely normalised across all of OpenStack
makes it more likely that someone will actually challenge the PTL if
there is a problem.
> there's no need to impose that process on every project. If
> they want to rotate the tech lead every week instead of every 6 months,
> why not let them? We'll soon see from experimentation which models work.
One cannot help wondering if we might get more Nova cores willing to
sign up for a 1-week commitment to be the "PTL" than we're getting for a
>> We also
>> still need someone to have the final say in case of deadlocked issues.
> -1 we really don't.
I still think I am mostly right about this (and I know Thierry still
thinks he is right and I am wrong ;)
IMHO it's never the job of the PTL to have a casting vote. It *is* the
job of the PTL - and all leaders in the project - to ensure that
consensus is eventually reached somehow; that discussion is not just
allowed to continue forever without a resolution when people disagree.
While all leaders should be doing this, I can see some benefit in having
one person who sees it as specifically their responsibility, and as
noted above the PTL election process ensures that this happens in every
In summary, I still think that in a healthy project the requirement to
have a PTL is probably mildly unhelpful. One thing that didn't come up
in that thread but that I have mentioned elsewhere, was that when I
became a PTL I very quickly learned to be very careful about what I
expressed an opinion on and how, lest I accidentally close down a
conversation that I was intending to open up. Because *overnight* people
developed this sudden tendency to be like "HE HATH SPOKEN" whenever I
weighed in. (This is very unnerving BTW, and one reason I feel like I
can be more helpful by *not* running for PTL.) So having a PTL means
giving up a core team member in some senses.
Ultimately, from the TC perspective it's a tool for reducing the
variance in outcomes compared to letting every team decide their own
leadership structure. As with all interventions that act by reducing
variance (rather than increasing the average), this will tend to be a
burden on higher-performing teams while raising the floor for
lower-performing ones. So that's the trade-off we have to make.
More information about the openstack-discuss