On 3/4/2020 12:57 PM, Zane Bitter wrote:
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-lead...
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.
I have been wanting to weigh in on this thread and was waiting for the right moment. Zane's input sums up how I feel as well. I think that having consistent leadership structure across projects is important and helps keep us aware of the health of projects. Perhaps we can help return interest in the PTL role by providing examples of teams that share the work and have the PTL to help make final decisions. I know that the Cinder team has been doing this for quite some time successfully. Jay