On Tue, Mar 3, 2020 at 16:44, Jean-Philippe Evrard <jean-philippe@evrard.me> 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.

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.

My context: We have a shortage of PTL candidates in Nova but we still have a core team. I think the real problem is that contributors think that being a PTL is a huge extra burden. I haven't been a PTL yet but I share this view. I think being a Nova PTL is a sizable amount of work. E.g. the PLT is the liaison by default if nobody steps up. And in Nova, according to the wiki, most of the liaison spots are filled by people who already left the community. So a nova PTL has a lot of hats by default. It could be that those hats does not need real work to be fulfilled. Still the list is long. So for me a better solution would be to rationalize (review, clarify) the list of expectations on the project teams. Then let the project teams commit to it either in a single person (a PTL) or by the whole team sharing the responsibilities between each other some explicit way. I can even accept that the project team explicitly rejects some of the responsibilities due to shortage of bandwidth in the team. For me explicitly not doing something is better than simply ignoring that such responsibility exists. I think Mohammed's proposal helps in a sense that removes the need to _find a single person as PTL_ in a situation where nobody wants to be a PTL. Basically removes the Nova core team from the wait-for-a-PTL-candidate state where we are in now. And in the same time it allows the core team to start discussing how to fulfill every responsibilities as a team. Cheers, gibi

Regards, JP

Le mar. 3 mars 2020 à 18:13, Graham Hayes <gr@ham.ie> a écrit :

On 02/03/2020 21:45, 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.

The above is just a very basic idea, I don't intend to diving much more in depth for now as I'd like to hear about what the rest of the community thinks.

Thanks, Mohammed

Yeah, this is a tough spot.

When we have talked about this in the past, we have theorized the role could be stripped back to "Project Liaison to the TC". As noted in other replies, the worry is that there is a lot of work that goes to the PTL by default currently.

We should look at this work, and if is it not bringing value, just remove it.

If it is bringing value, how do we ensure that someone does it?

My consistent worry with the removal of the PTL single point of contact, is that without it, this work will get missed.

I agree the best way to miss something is to spread responsibility between members, everybody thinks that others are watchful. -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

I agree with folks before me. As my predecessors have stated, throwing all folks into "maintainers" group/team would kill the responsibility relation. I believe we could get away with splitting the PTL role into multiple subroles and actually let each project decide on what these would be to satisfy that project's needs (but give some guidelines too maybe?). Also, it would make sense to allow assigning these on primary and secondary terms. Both would get "privileges", everyone is obviously responsible for itself, but primary is responsible if they are currently available and the role is POC-like. This way we could both lessen the load on PTL and officially allow vices. That said, these would need to get assigned and /me not sure how to best approach this atm. PS: Deprecate ask.o.o all the way. :-) -yoctozepto wt., 3 mar 2020 o 19:42 Michael Johnson <johnsomor@gmail.com> napisał(a):

Putting my former PTL hat on:

I agree with Slawek. I think the PTL role is still important.

That said, the list of responsibilities can get daunting.

I would lean toward re-affirming the "Project Team Leads" statement you linked and highlight, in the new contributor guides, that the other tasks can be delegated. Maybe we should also re-word that statement to clarify or soften the "manage day-to-day operations" part.

I think over the history of OpenStack we have had "hands on" PTLs and more "delegate" PTLs, both supporting healthy projects.

The lack of a clear "boundary" for the PTL role has probably lead to Fear-Uncertainty-and-Doubt. My hope is that the new contributor guide goal will help clarify the role. This may also highlight tasks that we can remove (deprecate ask.openstack.org anyone?).

Michael

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

Hi everyone, I see that the discussion has stalled out, I'd like us to seriously explore this because I think come the PTL time, we might run into a lot of projects who don't have folks stepping in. Thanks, Mohammed On Fri, Mar 13, 2020 at 1:37 AM Renat Akhmerov <renat.akhmerov@gmail.com> wrote:

On 5 Mar 2020, 02:57 +0700, Jay Bryant <jungleboyj@gmail.com>, wrote:

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.

I really fail to understand the issue of an overwhelming PTLship. From my personal 5+ experience of being a PTL, I can say I’ve never tried to do all stuff like releases, fixing CI, back porting etc. etc. myself. Especially given that I really like solving technical problems, I always try to offload some of these duties to others and make sure I have time for development. And IMO it’s totally fine. As a PTL I try to make sure that everyone in the team (at least most active members) has this balance between problem solving and necessary procedures. I absolutely agree though that as the PTL I have to know what’s going on with the project and after all TC or someone else can ask me about its current state and progress. Of course, I realise that my project is somewhat not really typical for OpenStack: it is relatively small and has not so many connections with other projects. But I believe this principle is universal enough. As far as the PTL role, I think for PTLs it’s important to focus on the big picture, ideas and directions and keep reminding everyone about that. All team members, even active ones, often can’t afford thinking about this too much. This contradicts with lots of what I heard before from my former managers and colleagues, and also some PTLs I know. They claimed: “PTLs just need to maintain Launchpad (or Storyboard), keep an eye on the release process and that’s basically it. Plus reviewing a little bit.” I’ve always shrugged when hearing this.. If so, let’s remove “L” from “PTL” and replace it with “A”, so that it’s “PTA” - Project Technical Administrator. Something that can legally exist, no issue. And it’s more honest. What I’m going to is, from my perspective, it probably doesn’t make any difference if a project leader is an official role or not. I guess there will always be someone who naturally gains trust of others and influences the direction of a project. As far as “having a final word on a deadlocked issue” I thought this is something really important but, in fact, it’s a very rare thing and may not be needed at all. Usually, we have to make a decision anyway, since “not making a decision is more expensive than making even bad decision”.

So I believe some leadership is always needed. The most high quality techs I’ve ever seen have been all made with a very strong leadership, I don’t believe it works the other way. Whether it’s official or not, I think is not important at all. But “administrative duties” that often assign to PTLs can be easily split between people.

Thanks

Renat Akhmerov @Nokia

-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://vexxhost.com

On Wed, 18 Mar 2020 at 13:05, Mohammed Naser <mnaser@vexxhost.com> wrote:

Hi everyone,

I see that the discussion has stalled out, I'd like us to seriously explore this because I think come the PTL time, we might run into a lot of projects who don't have folks stepping in.

We could let the elections take place and see how many teams this will apply to. Those teams could then decide how to handle the situation, and report results during the cycle. Based on their experience we could change the model for V. It seems to me that a relaxing of some conditions and expectations on project leadership might be more appropriate than a blanket change.

Thanks, Mohammed

On Fri, Mar 13, 2020 at 1:37 AM Renat Akhmerov <renat.akhmerov@gmail.com> wrote:

...

On 5 Mar 2020, 02:57 +0700, Jay Bryant <jungleboyj@gmail.com>, wrote:

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.

I really fail to understand the issue of an overwhelming PTLship. From my personal 5+ experience of being a PTL, I can say I’ve never tried to do all stuff like releases, fixing CI, back porting etc. etc. myself. Especially given that I really like solving technical problems, I always try to offload some of these duties to others and make sure I have time for development. And IMO it’s totally fine. As a PTL I try to make sure that everyone in the team (at least most active members) has this balance between problem solving and necessary procedures. I absolutely agree though that as the PTL I have to know what’s going on with the project and after all TC or someone else can ask me about its current state and progress. Of course, I realise that my project is somewhat not really typical for OpenStack: it is relatively small and has not so many connections with other projects. But I believe this principle is universal enough. As far as the PTL role, I think for PTLs it’s important to focus on the big picture, ideas and directions and keep reminding everyone about that. All team members, even active ones, often can’t afford thinking about this too much. This contradicts with lots of what I heard before from my former managers and colleagues, and also some PTLs I know. They claimed: “PTLs just need to maintain Launchpad (or Storyboard), keep an eye on the release process and that’s basically it. Plus reviewing a little bit.” I’ve always shrugged when hearing this.. If so, let’s remove “L” from “PTL” and replace it with “A”, so that it’s “PTA” - Project Technical Administrator. Something that can legally exist, no issue. And it’s more honest. What I’m going to is, from my perspective, it probably doesn’t make any difference if a project leader is an official role or not. I guess there will always be someone who naturally gains trust of others and influences the direction of a project. As far as “having a final word on a deadlocked issue” I thought this is something really important but, in fact, it’s a very rare thing and may not be needed at all. Usually, we have to make a decision anyway, since “not making a decision is more expensive than making even bad decision”.

So I believe some leadership is always needed. The most high quality techs I’ve ever seen have been all made with a very strong leadership, I don’t believe it works the other way. Whether it’s official or not, I think is not important at all. But “administrative duties” that often assign to PTLs can be easily split between people.

Thanks

Renat Akhmerov @Nokia

-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://vexxhost.com

On Thu, Mar 19, 2020 at 10:04 AM Sean Mooney <smooney@redhat.com> wrote:

...

On Wed, 18 Mar 2020 at 13:05, Mohammed Naser <mnaser@vexxhost.com> wrote:

...

Hi everyone,

I see that the discussion has stalled out, I'd like us to seriously explore this because I think come the PTL time, we might run into a lot of projects who don't have folks stepping in.

We could let the elections take place and see how many teams this will apply to. Those teams could then decide how to handle the situation, and report results during the cycle. Based on their experience we could change the model for V. It seems to me that a relaxing of some conditions and expectations on project leadership might be more appropriate than a blanket change.

On Thu, 2020-03-19 at 09:19 +0000, Mark Goddard wrote: the issue is that the bylaws do not currently allow that. so what was currently being proposed would allow every project to continue as before electing ptls but it would no longer make it mandatory for the tc to appoint a ptl if none was elected.

or we can just appoint TC members to fill that spot

currently all projects in the govance repo must have a ptl defiend. so if we do nothing the tc will have to intervene for any project that does not elect a ptl.

...

...

Thanks, Mohammed

On Fri, Mar 13, 2020 at 1:37 AM Renat Akhmerov <renat.akhmerov@gmail.com> wrote:

...

On 5 Mar 2020, 02:57 +0700, Jay Bryant <jungleboyj@gmail.com>, wrote:

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.

I really fail to understand the issue of an overwhelming PTLship. From my personal 5+ experience of being a PTL, I can say I’ve never tried to do all stuff like releases, fixing CI, back porting etc. etc. myself. Especially given that I really like solving technical problems, I always try to offload some of these duties to others and make sure I have time for development. And IMO it’s totally fine. As a PTL I try to make sure that everyone in the team (at least most active members) has this balance between problem solving and necessary procedures. I absolutely agree though that as the PTL I have to know what’s going on with the project and after all TC or someone else can ask me about its current state and progress. Of course, I realise that my project is somewhat not really typical for OpenStack: it is relatively small and has not so many connections with other projects. But I believe this principle is universal enough. As far as the PTL role, I think for PTLs it’s important to focus on the big picture, ideas and directions and keep reminding everyone about that. All team members, even active ones, often can’t afford thinking about this too much. This contradicts with lots of what I heard before from my former managers and colleagues, and also some PTLs I know. They claimed: “PTLs just need to maintain Launchpad (or Storyboard), keep an eye on the release process and that’s basically it. Plus reviewing a little bit.” I’ve always shrugged when hearing this.. If so, let’s remove “L” from “PTL” and replace it with “A”, so that it’s “PTA” - Project Technical Administrator. Something that can legally exist, no issue. And it’s more honest. What I’m going to is, from my perspective, it probably doesn’t make any difference if a project leader is an official role or not. I guess there will always be someone who naturally gains trust of others and influences the direction of a project. As far as “having a final word on a deadlocked issue” I thought this is something really important but, in fact, it’s a very rare thing and may not be needed at all. Usually, we have to make a decision anyway, since “not making a decision is more expensive than making even bad decision”.

So I believe some leadership is always needed. The most high quality techs I’ve ever seen have been all made with a very strong leadership, I don’t believe it works the other way. Whether it’s official or not, I think is not important at all. But “administrative duties” that often assign to PTLs can be easily split between people.

Thanks

Renat Akhmerov @Nokia

-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://vexxhost.com

On 3/4/20 12:57 PM, Zane Bitter wrote:

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.

That's a really interesting idea. I'm not sure I'd want to go as short as one week for PTL, but shortening the term might make it easier for people to commit. It might be a small issue come project update and cycle highlights time since no one person may have the big picture of what happened in the project, but ideally those are collaborative things that the entire team has input on anyway.

The key would be to make it short enough that you can be 100% confident the next person will take over and not leave you holding the bag forever. (Hi Rico!)

I've no idea where the magic number would fall, and it's probably different for every team. I'm reasonably confident it's somewhere between 1 week and 6 months though.

I think one potential benefit from this comes in the form of killing one of the other thngs that Zane mentioned (which I totally agree with): The "(s)he hath spoken" part. I can imagine getting to the point where not everyone on the team remembers exactly "who is PTL this month" and certainly the long tail of minor contributors would lose visibility into this. I think that would dis-empower (in a good way) the PTL-this-month person both from the perspective of being the constant (even if unnecessary) decider, and the sounding board for everyone trying to push their pet efforts through the works. Although I'm calling "not it" for the month containing the PTG right here and now ;P --Dan

On Thu, Mar 5, 2020 at 8:59 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:

Another idea I think about co-PTLship. I remember in previous or this cycle few projects want to have the co-PTL concept. Means officially have more than PTL. To solve the single point of contact issue we can have single PTL contact and other co-PTL distribute the responsibility for

that cycle.

IMO that's a good idea for sure, and that's how the Telemetry team is doing right now (two co-PTLs) But from my part, PTL is really not that huge needed for leadership but a lot of maintaining works. This makes me tend to agree that `Maintainers` is the right word (along with other nice choices). In the long term, merge `core team` into the `Maintainers`? :) And to specifically define, I don't think this change means the project is under maintenance mode. Features should still welcome to innovate each project we have. And we should specifically mention that to avoid any confusion people might have here. -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin

On Thu, Mar 5, 2020 at 3:07 AM Graham Hayes <gr@ham.ie> wrote:

On 04/03/2020 22:43, Zane Bitter wrote:

...

On 4/03/20 3:08 pm, Ben Nemec wrote:

...

On 3/4/20 12:57 PM, Zane Bitter wrote:

...

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.

That's a really interesting idea. I'm not sure I'd want to go as short as one week for PTL, but shortening the term might make it easier for people to commit.

The key would be to make it short enough that you can be 100% confident the next person will take over and not leave you holding the bag forever. (Hi Rico!)

And also that the person you hand it off too won't have to hand it back. (Hi Tim!)

...

I've no idea where the magic number would fall, and it's probably different for every team. I'm reasonably confident it's somewhere between 1 week and 6 months though.

Yeah - I am not sure the TC should mandate a number - some teams might be OK with the 6 months, while others will need to do 1 or 2 weeks

I would like to think elections would NOT get held every 1-2 weeks or whatever the chosen PTL term is for a project? Its just a like...signup sheet sort of thing? What if more than one person wants to sign up for the same week( I can't think of why this would happen, just thinking about all the details)? -Kendall (diablo_rojo)

On 3/5/20 12:29 PM, Kendall Nelson wrote:

On Thu, Mar 5, 2020 at 3:07 AM Graham Hayes <gr@ham.ie <mailto:gr@ham.ie>> wrote:

On 04/03/2020 22:43, Zane Bitter wrote: > On 4/03/20 3:08 pm, Ben Nemec wrote: >> >> >> On 3/4/20 12:57 PM, Zane Bitter wrote: >>> 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. >> >> That's a really interesting idea. I'm not sure I'd want to go as short >> as one week for PTL, but shortening the term might make it easier for >> people to commit. > > The key would be to make it short enough that you can be 100% confident > the next person will take over and not leave you holding the bag > forever. (Hi Rico!)

And also that the person you hand it off too won't have to hand it back. (Hi Tim!)

> I've no idea where the magic number would fall, and it's probably > different for every team. I'm reasonably confident it's somewhere > between 1 week and 6 months though.

Yeah - I am not sure the TC should mandate a number - some teams might be OK with the 6 months, while others will need to do 1 or 2 weeks

I would like to think elections would NOT get held every 1-2 weeks or whatever the chosen PTL term is for a project? Its just a like...signup sheet sort of thing? What if more than one person wants to sign up for the same week( I can't think of why this would happen, just thinking about all the details)?

Yeah, this logistical problem is one of the reasons I didn't want it to be a one week rotation. I guess maybe you could solve that by holding elections each cycle, but selecting a pool of PTLs who could then trade off as desired, but at that point I feel like you're back to not having a PTL and instead having a maintainer team. It also seems like a potentially complicated election system. Plus it kind of introduces a problem with the PTL being the point of contact for the project. If it's changing weekly then you lose most of the benefits of having a single person other people know they can go to. I'm also wondering if this actually solves the "Hi Rico!" case anyway. :-) If a PTL leaves the position because their focus has changed, they aren't likely to take it back even if the new person only technically signs up for a week. When your PTL candidate pool is exactly 1 then it doesn't matter if they're getting elected weekly or six monthly. I guess the idea is for this to increase the pool size, and whether that will work probably depends on the circumstances for each project. Anyway, I still think it's an interesting idea, even if I have come up with a few new concerns after further consideration. Maybe it's something a few teams could experiment with initially and see if it works and what timeframes are appropriate?

-Kendall (diablo_rojo)

Thierry Carrez wrote:

[...] So one solution might be:

- Define multiple roles (release liaison, event liaison, meeting chair...) and allow them to be filled by the team as they want, for the duration they want, replaced when they want (would just need +1 from previous and new holder of the role)

- Use the TC as a governance safety valve to resolve any conflict (instead of PTL elections)

Proposed as a strawman at: https://review.opendev.org/#/c/712696/ Feel free to comment on how crazy that is there... -- Thierry Carrez (ttx)

On Thu, 2020-03-12 at 18:09 -0400, Brian Rosmaita wrote:

On 3/12/20 10:37 AM, Thierry Carrez wrote:

...

Thierry Carrez wrote:

...

[...] So one solution might be:

- Define multiple roles (release liaison, event liaison, meeting chair...) and allow them to be filled by the team as they want, for the duration they want, replaced when they want (would just need +1 from previous and new holder of the role)

- Use the TC as a governance safety valve to resolve any conflict (instead of PTL elections)

Proposed as a strawman at: https://review.opendev.org/#/c/712696/ Feel free to comment on how crazy that is there...

Maybe the proposal itself is crazy, maybe not, but the timing of this is certainly crazy.

at least form a nova perspecitve this is an appriate time as we were in a postion where due to changes in errics employment he would not be able to continue with his role as novas ptl. with as you indicate later ther are many factors going on currenlty on the world at larage and in people personal and internal commitments so we were in a postion where we might not have a candiate to take over until the next election and we may or may not have candidates for that election. fortunetly gibi has been able to find time to become novas interim ptl for the rest of the ussuri cycle. i am not going to speak on behalf of nova but i suspect that if the core team had the option of moving to a ptl less model then they might just do that as from my experince nova ptl have never or very really been in a postion where they must be a tie breaker between other cores out side of there normal role as a core themeses. so for nova i dont think that aspect of the ptl role is partically relevent as the core team general reaches consensious without requiring a ptl to step in and make a dessions. given the lack of ptl candiages over the last few cycle i think removing hte need to have a candiate run in a election would encurage decentralistion of the set of jobs that defualt to the ptl. if gibi or someone decied to run as ptl for victoria have the flexablity to not require a ptl does not perculde operationg as we do today, it just takes the pressure off contiutors as we wont have to involve the tc if noone puts there name forward for the election. we can fall back to a ptl less model and just ensure that each of the function are performed by someone in a timely manner. so if this was to proceed i was hoping that it could take effect form the victoria cycle. that said i dont dislike the ptl role, i think it has served use well and could continue too but this is not the first time in the last few release where i fell like the requirement for there to be a ptl has been more harmful then helpful as i think without a nominated ptl the work would still have got done more organically with less process.

This is not a good time to be having this discussion. We're just about to start week R-8. The final release for non-client libraries is at R-6, the final release for client libraries and feature freeze is at R-5. So there is (should be) a lot of stuff happening in the projects right now, that may preclude people from being as active in this discussion as they might wish. Plus, I don't know about y'all, but the current pandemic is making simple day-to-day living more stressful on me than it was a few weeks ago.

What I'm saying is that I'd appreciate clarification on the timeline for this change. This is the kind of thing that could use discussion at the PTG. If the point of Thierry's patch is to prepare for discussion at the PTG, then that's great, I personally will revisit it at R-1, and be ready to have a productive discussion. But I think this is not a good time to make the usual "silence is assent" inference to a proposal floated on the mailing list.

cheers, brian