[all][tc] Moving PTL role to "Maintainers"

Zane Bitter 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:
> 
> https://governance.openstack.org/tc/reference/charter.html#project-team-leads
> 
> 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:

http://lists.openstack.org/pipermail/openstack-dev/2014-August/043826.html

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 
aged :D

> 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 
> usefulness.

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 
6-months-and-maybe-indefinitely commitment.

>> 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 
project.


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.

cheers,
Zane.




More information about the openstack-discuss mailing list