Open Stack

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