 So, thanks for showing up. Our talk is called Being a PTL, the Good, the Bad and the Ugly. I see a lot of previous PTLs in the audience, so that's good. Hopefully you guys can actually just get a lot. I mostly just want people to laugh in this session. I like stories. This is going to be story time around the campfire, so I'm glad they just closed the doors. So, thanks for joining us. I already got one. Okay, so the presenters are, this is Matt Readiment. He works for Huawei. I'm Steve Martinelli. I work for IBM. This is Armando. Oh, that's very good. Oh, Martinelli. Come on. He works for SUSE. So before and after, we figured we'd break the ice about what you, an accurate depiction of what you look like before taking on PTL and then doing it for three times. Just as a precursor, Matt has been, this is his third time as the Nova PTL. I've done it for three times for Keystone. Armando did it three times for Neutron. Look how sharp I was. So again, it's a very accurate portrayal of what looks like and kind of looks like that. So you know, the first you're very young, full of hope, full of energy, and then by the end you're just kind of grizzled and angry all the time, or if you're Matt you were angry all the time to begin with. And still youthful and beautiful. We were thinking about putting up a third preacher there. That kind of shows myself and Armando with, you know, Obama jet sking, or. So okay. The joke's over. All right. Perception versus reality. How people perceive the PTL versus the reality of the situation. This was very much, I wrote this section based on how I felt when I first started working on OpenSec and working with Dolph Matthews, the first Keystone PTL, and I felt he was like Superman. But I put Iron Man up there because he's cooler. So I felt like the PTL knew everything about the project. He figured out, he made all the decisions. He was the best coder on the team, and like a super reviewer, all was up there on Stackalytics. Number one, PTL. Most reviews. The reality is very different. Once you actually step into the shoes, we don't know everything at all. I say this a lot, there are many sections in the code base. I have never touched, and I have no idea what they do. So we are not psychics, nor are we historians. We are definitely not dictators either. We plead. We're moderators, we're liaisons with people. We try and connect people and come to a common agreement. And secondly, we're not the best coder. We're not always the best coders. Dolph was, but I definitely was not. That's why they put me up. They made me PTL. Sometimes you're rather proud that you haven't touched a specific area code, or you're ashamed that you've touched that area code. And we don't just review code. There's probably 20 other things you have to do. You have to ensure the gate's not broken. You have to nominate cores, decore people, which is super awkward and painful. You got to tree out all the bugs, because no one wants to do that. You have to make sure the gate isn't broken, and all the stable's fine, and this is just, and we're going to get into that, because that's the good and the bad and the ugly going forward, but there's a lot more than just reviewing code. So you want to become a PTL. So hopefully there's a few aspiring PTLs in the audience that are wondering, all right, how do I become a PTL? More so, why would I want to become a PTL? So how? So things you want to do. You want to work from the ground up. You want to get your feet wet. You want to start reviewing code. You want to become a core reviewer. And then from there, you can maybe toss your, put your, put your name in there for the next time the PTL voting comes around. Next, I always recommend people become known across multiple projects. You're going to have a lot of cross collaboration, cross stream, crossing streams, and with various other projects, you know, Oslo's an easy one to get involved into because everyone uses it. So make sure you're working with the release team, the Oslo team, the docs team. Make yourself available. Make sure you have a bouncer set up so you're not missing messages. Obviously review code, become a core, and most importantly, work well with others. You'd be surprised how not obvious that is. The don'ts. Don't piss people off. Don't think you know it all. Don't work in isolation and don't push a company agenda. It's open stack first, company second. And, you know, you're going to have to work with a lot of different people, with a variety of backgrounds and skill sets. So you have to be able to work with others. And that's why you can't work in isolation. And why would you want to become PTL? You have solid understanding of the project, and you want to grow as a person. You're really good at cat herding for some reason. And you have enough time to devote to upstream work, enough time to devote to upstream work, and you have to devote to upstream work. So that's not a typo. That's not a typo. We actually wrote that there because you're going to be doing it a lot. It's a lot. Bad reasons. Management asks you to run for PTL. That's not a good reason. You have to want to do it yourself. Other bad reasons is to promote a company agenda. You know, there's various instances of that where people just want to do what their company wants. And I think that's less now, it was more so in the past. But it's still an issue. And leverage for more money, I mean. That's not a good reason at all, because that's not true either. I didn't see an extra dime, actually, in my case. Me either. There you go. All right, now Matt's going to talk about, sorry, you're going to talk about the good portions of being PTL. Here you go, sir. So, well, thanks for bringing the ice. So let's, let's, there you go. So I'm, I'm apparently supposed to be the positive guy of the trio here. Even though I'm exactly the opposite, but I'll give it a try. So, well, okay, now, in all seriousness, I think this, the experience of being a PTL teaches you a lot. You learn a lot more about yourself, not just from a technical standpoint, but also from a human, like, a social standpoint. And as engineers, as most of us are, practicing soft skills is something that you don't necessarily do when sitting in front of a screen, typing code in day in, day out. But when you are an IRC or where you are a PTG in these days or some it's a while back, you have to obviously get together with people, try to bridge barriers and communicate. And again, practice soft skills as much as you can. Once obviously you mastered, you crafted those skills, there is the chance for you to pass that knowledge on. And you, you know, you're perceived as the elderly of the team and people look up to you as a way to, to learn those skills and get those skills transferred. So there is a tremendous growth opportunity, you know, from, from, again, from the technical point of view as well as the human point of view. And being able to inspire other people throughout their growth process, it's something that is rewarding. Having said that, though, there is an awful lot of work involved. Steve mentioned about the dirty work required to keep the lights on, on a daily basis. And I've spent many days trying to keep the neutral gate up and running. I hope I can get a little bit of space. But that is all good stuff, right? That is still good stuff. I mean, because at the end of the day, I mean, I actually, you know, I personally have pride, you know, find pride and joy when I end up like killing a race condition. There is a reward in doing the dirty work and knowing that you've fixed the issue and other people who depend on you will be able to then do their work more easily. Well, I mean, when I get a plus two from Sean, I mean, it's like, come on, that is amazing. And it's like, that doesn't happen very often. So, I mean, so mentoring other contributors, put them in the position to do well as you did to get to the point where you achieved, it's something that, again, it's very rewarding. Working with other projects, you know, getting Matt to say yes and get him to do the work. I mean, for instance, something that I'm pretty proud is getting a network feature that we developed between Neutral and Nova. That's something that takes a great deal of effort. Once you get to the finish line, it's a very rewarding experience. So coordinating feature development across projects. Yeah, I think when you work on these major cross-project initiatives and not just ones that sweep across all projects, but ones that are longstanding issues, like moving over to V3 of the Identity API or moving over to the Keystone middleware from Keystone Client, it's very rewarding when you see the work done. And I think that's just human nature to see that work done. And you've put a lot of thought into it. You've planned it, it's gone through, and it's done, and it's just very rewarding, I think. Right, yeah, I mean, making progress, right? Moving forward in the right direction and see that you are making an impact, it's the good about this job. Good? Go back. Damn it. All right, so, and for that, obviously you get to recognize as a person who has made an impact. So, you know, you get people to upload the efforts that you put in there out. You, obviously, because of that, have an increased visibility within the community. So, for instance, you may end up being pulled into, sometimes not necessarily something that you look for, but you get pulled into doing podcasts or interviews and some people like that, especially if you can get, you know, to practice your accent. You know, it's like, I mean, if I can find an opportunity to, you know, practice my English, it's always something that I appreciate. Well, they also promise you lots of beer. I've actually never seen any, which my, like, liver appreciates, but, yeah, sometimes, you know, they say, well, if you can help me with that, I can give you lots of alcohol. So, that's something that, you know, I can be perceived as a good thing. People look up to you and praise you for stepping up, you know, for carrying the burden of the project. And there is a, you know, a great propeller for you to, you know, step up and put the many hours that you gotta put in for the job. When you step down, go on. No, no, go ahead, go on. No, when you step down, they, you know, if you're done with your job, there is also very rewarding, the nice words that come from many folks like. So, there is also something that you really appreciate. So, what are you saying? On a note on the promised libations, it was, people will bug you because, as PTL, you are the face of the project, right? Correct. If anyone has a random question about how to use a command line utility, how to, you know, all my patches emerge conflict, how do I do that? Is, or help me merge this doc patch. You help anyone for anything, and that's where they're gonna tell you, hey, yeah, I'll get you a beer at the summit. But, stepping back a minute there, being the front face of the project means you are the go-to guy for everything. And I personally love being the go-to guy. It's a love-hate relationship. You hate it because people are messing with you all the time, but I really like helping people. So, yeah, it's a high amount of volume, but I really get a lot of satisfaction helping people work around issues that they're facing. Yeah, I mean, even if you can't help them understand, you being the go-to person, know how to redirect that person to the right person. So you become like a dispatcher, like, yeah. Yeah, dispatcher. And you learn the art of delegating. So if you wanna go into management and you want to learn how to delegate, they do nothing from that point onward. That's something that you may want to consider. All right, so I think we're gonna go into the bad part, and for that, Matt is gonna practice his skills. Yeah. Appropriate. I'm not, Sean knows I'm not one to complain, but there's a couple things, I guess. The biggest issue for me, I guess, is being stretched in. There's a lot of different working groups in OpenStack, and a lot of these answers that we think for why, if we just had people focusing on this one thing for like six months, it would be done. So let's create a working group. And, or how do we fix communication problems between product managers at companies and the developers and the operators, and well, it was to create like 20 operating, or 20 working groups, and it'll magically happen, and who's gonna relay the message? And generally the default is supposed to be the PTL. It doesn't really always happen. All of the stuff that's going on in other projects, trying to keep on top of that, like we said about cross-project, working on big cross-project efforts, like get me a network, the Keystone V3 things, and knowing that other projects have priorities that don't necessarily work with what our priorities are, release management. This is, it's sort of listed as a bad thing, but I also wanted to point out that the slide about like how do you eventually get it, step up into these leadership positions is doing the dirty work of like release management, staple branch stuff, fixing gate issues, and really just doing a lot of the day-to-day grind that lets the other people in the project that are actually working on coding and fixing and doing really tough development issues do their job without being totally distracted by everything else. Roadmaps, roadmaps is something I didn't really anticipate when I first became PTL and they were like, we need you to talk about the thing you're gonna work on a year and a half from now, and working for a large corporation, sure you get questions like that, but not at my level really at the time, it was like, well there's some guy that gets paid way more than I do, and I'm sure he's got an idea that will never come, you know, be actually visualized, but whatever, but so you get asked these sorts of questions, it's like, I don't know, and then feeling bad because you don't know. So the reality is that you're really a liaison like Armando said, it's a dispatcher. Workload, I think this is for, you don't have to be PTL for this, this is really just a developer, an open stack or a core reviewer, just being able to go on vacation, like Sean has told me numerous times that I am just terrible at vacationing. This is always, you know, what you think you're gonna do for five minutes when you drink coffee in the morning on vacation, checking email turns into your spouse yelling at you by 11.30, you know, like we were supposed to be out of here by 10 and you're still doing stuff. It's like, well, everything's on fire and I just, you know. I'm the only one that can put it out. Yeah, right. You know, when you realize that you have a problem, when you go on vacation abroad for your own personal reasons and you're buying a very expensive data plan so that you can connect on IRC, that's when you realize that you have a problem. Yeah, I at least didn't bring my laptop to Europe last summer. I don't have an IRC bouncer. I did, I do sort of, I did sort of, well, I don't send that work from home now. I can't really turn it off, but I used to maybe like one or two days a week. I would just like leave my laptop at work and go home and that's how I would disconnect. I would force myself to disconnect. And I think another thing that makes you realize that you have a problem is when you plan your vacations around the lease schedule, the open stack lease schedule. Like I can't go on vacation on that day because that's bishopries. Right, there's, I think that's one of the things on the ugly slide. It's the bad and the ugly sort of all merged together. The ever-growing backlog, the PTGs and the summits are great for working through existing issues, but I always feel like we come out of them with new work, new stuff sort of piled on. And there's always a focus for 10 years from now. It's the roadmap stuff. How are we, like what are we gonna do now so that in Rocky, like we're actually using limits from Keystone or something. And it's like, well, remember that we can't live migrate pinned CPU VMs or something that we haven't been able to do for two years and people still are angry about that. And then the inevitable crunch at the release candidate. I mean, you know it's coming and we still screw it up, like every release. I don't, there's not really anywhere around that. Everything else is sort of dealing with the scale, the email explosion. I was talking to somebody, a new contributor that came to one of the NOVA Project on-boarding things at lunch today, and she just was like, how do I ask questions about anything? And the good part is you are close enough to working with new contributors so that you can remember what it was like being a new contributor, because after four or five years in, it gets easy to forget. But just a simple like, well, there's this development mailing list, right? But first thing you wanna do is set up filters and like filter everything and don't attempt to read all of the things. Just stick to one project or one topic and do that. So you learn these scales a bit. The gate blowing up, I don't know. I mean, it's a love hate. I actually really, there's like some sort of weird, I don't know, like pain and tolerance of just like everything is on fire. But this is like exhilarating, so let's fix it. That's why you made the elastic recheck, right? No, I didn't make it. That was Joe Gordon and Sean and some other people. But it was like a, I don't know, it was just, it's fun at the same time. It's weird. The bug backlog, that is not fun, I would say. I am never enjoying having 800 some bugs in the Nova backlog. I actually figured that out. You just marked them all invalid. It happens. Because they're no longer relevant now. Yeah, Marcus did that for a little while. But somebody does do the work. Somebody does go through there like once a year and close a few dozen maybe. It's also sort of, it's hard to motivate people to actually care about bug triage. So even though I bring it up in every Nova meeting, I'm like, hey, guess what? We're over 85, there's this weird threshold of like, if it's over 70, I'm sort of like red flag. People need to start caring, but nobody cares. Test coverage, it's another thing to always be harping on is, well, this failed, why didn't we catch it in CI? What can we do to add CI for this? And how do you get people to actually do the work to add it? And then just team meetings. And I will pass it on to Steve, who's not ugly about ugly stuff. Why, thank you. Yeah, flattering, thank you. One note about team meetings. I remember not being PTL and not paying attention during the team meetings, unless it was my turn to talk. Sometimes I would just kind of tune out a few minutes. But now that when I was PTL, it was infuriating to know people were doing the same thing. It was like, I've messaged someone and I just spoke to you before the meeting. Now that the meeting's on, somehow you are not responding to my opinion as it's your turn to talk. However, it is fun to call them up, knowing that you're gonna trap somebody and calling them out. That's true, you control people in the meeting. It's kind of fun. Yes, Jeremy does not recommend it to tune out while chairing the meeting. That's actually another thing you could do if you're interested in becoming PTL, volunteer to chair the meeting. It's good experience. You get to learn all the different IRC shortcuts. John Garbut is in the UK and he was PTL before me and with the time zone we have different weeks, we do different meetings at times and that's really, John didn't wanna be running a meeting at nine o'clock at night in surprise for whatever reason. So I would run them. So now I'm gonna quickly talk about the ugly portion. So managing expectations, this can be hard. Contributors can be very upset at you. And I'm Canadian so I'm used to saying sorry. But when you minus to a spec and I just say sorry, this just isn't meeting our requirements. Yeah, you can work with them but it's already past spec feature freeze and you feel terrible because someone put this effort into it. It just didn't get reviewed because everyone swamped and now they gotta wait another six months and it's just, people will not like you for that, unfortunately. And it's just a reality of. You just gotta delegate someone else to say no. Yeah. Trying to justify your upstream time to your employer. I was lucky enough that when I was PTL, it was 100% of my time was upstream. That was totally cool with the employer. It was great. Other people are not as fortunate and it's very difficult to justify why you're doing this if it's not making us any money. Or why don't you work on the product? You have all the expertise to lead the project. Why don't you work on it on the downstream side? It's difficult. And then you gotta manage upstream relations. So first you have to work well with the other PTLs and other projects. You gotta work well with the infer PTLs, the docs PTL, the release management team, and even the TC at times. And it's really disappointing when previous PTLs who have all that kind of tribal knowledge just vanish. Or there was back when we had that small window of time where it was still just after milestone three and before release candidate, that's when the election would happen. And if the baton was handed over, sometimes the baton handing would be a little awkward. It was more of a throw it in someone's back. We're like, all right, you finish off this release, I'm out of here. That can get a little awkward. The other one is team dynamics. I mean, there's a lot of core things. Took a long time to find that picture. There's the core team, this is managing the core team basically. And it's, in Keystone there's 10, 12 people. I don't know how many cores you have in Nova, more than that and more in Neutron. And everyone's got different personalities, different ways of interacting. And it's that many people in one room even at the PTG can get awkward. So you kinda have to be mom and dad to a bunch of adults sometimes. And it's, you know, I didn't sign up for this. I wanted to run a project, why am I doing this? And aside from that also you have to add core reviewers and it may seem easy. Yeah, okay, this person been reviewing a lot, make them a core, but it's more complicated than that. It's what company do they work for? Have they contributed enough? Am I, I've had to think about these decisions for weeks sometimes. It's not always a clear cut case. And the hardest part for me was actually decoring people because, or removing them from the core team. Cause, you know, even though they may not be active, it's, you know, they're not harming anyone. Why do I have to do this? And it's kinda, you'll take it a little bit personally if it happens, if you are removed from core for something cause you worked so hard to get there. Now someone's taken it away from you. However, there is like a, there is this perception that if you do have a lot of cores that you should be pushing through more code or more throughput. And it's like, well, it says that we have 15, but there's really like seven. So I've decored people just because of like, being honest about what the actual numbers are. Cause when the TC and the foundation people are like, what's going on? It's like, well, this isn't really a real number. Exactly. And it just kinda gets awkward. And then you're gonna have arguments over IRC over mailing this and you know, you're forced to kinda be the sheriff in your channel. You have to kick people for being troublesome, putting it lightly. So one way to summarize this, we're all engineers so we wanted to kind of portray this in a way. So if the good is the green line, bad is kinda relatively steady I think and the ugly, you get used to handling the ugly. So if it were three different points in the graph, it was the honeymoon's over. You got elected, congratulations. This big bag is yours now to hold. I'm not gonna say what's in the bag. Candy. Candy. B is probably a month or two into it or probably maybe halfway through a cycle. You're like, oh God, why'd I sign up for this? So the ugly is outweigh the good, right? Yeah, then the ugly outweighs the good. You start to realize that the bad is coming and it will be steady, bad. Yeah. Shoot whatever. And then it's release crunch time and no one is reviewing code. They're all just pushing more and more patches. And then lastly you kinda realize you have this epiphany of like, all right, this is relatively steady. I can handle this one. So that's the point where you gain experience, you learn what to expect for the TCs, not changing the rules under you and you're good to go. Yeah, there's no more surprises, exactly. I think for like all, like any of us that have been around for a while, you also realize that there's this up and down of, you know, Barcelona was a little depressing. The OSIC thing, I mean there are these big things that happen in the community and it gets like everybody sort of depressed for a while but then like if it's happened a couple of times you get out of it and you know that you're gonna come out the other end of it. So to conclude, I really want, I know we, there's unfortunately, I don't know why I picked the title but it gave you the perception that there was more bad than good because it's bad and ugly. But it's not quite accurate. I mean, I really enjoyed being a PTL and I feel the good far outweighs the bad and the ugly combined. You come out a very changed person, you learn a lot about yourself, how you handle workload, how you delegate, you know, whether or not, you know, when your workload hits a crazy amount of time are you gonna buckle down, do it all yourself or are you going to delegate to other people and help you out? Do you trust those other people to help you? And that's an important skill that I think people don't get a chance to kind of figure out unless they're put in this position. But you know, of course, it must be fun because we did it three times each. So it's gotta be fun if you keep agreeing to do it. Sure. So the point of the talk was to just kind of peel back the curtain a little bit of what it means to be a PTL, you know, perception, reality, what we actually do. And if you see a PTL around, they're probably overworked and just kind of give him a hug except for Matt, he doesn't do hugs. No? Give him two, exactly. Jim loves hugs. Yeah. All right. Delegate the hugs. Question. All right, any questions? Also, the mics are over there if you wanna ask the questions, otherwise I will go and repeat them. So since there's so many current and former PTLs in the room and keeping in mind I'm totally gonna hold you all to this, can I get like a rough timeline sort of sense? Like from your first commit to becoming a core, from becoming a core to becoming a PTL, realizing there's gonna be wild variants all around. But I mean, you people on the stage like look like you're about 21, 22, some of you. So it couldn't be that long, right? So that's what I'm like a little curious like, how long does that pull? I think it took me about a year to become a core and another year until I felt comfortable, you know, putting my name in there for PTL. Yeah, I guess it varies from from project to project. In my case it took me six months to become core and then I was able to stay away from the role for as long as I could until the point where I had to do it and I think that was about two years. So yeah, I think that's about it. I think it was about when I actually like was working full time, mostly upstream, it was a year to year and a half to core and then like two years later, I think it was PTL. And it's a classic PTL trick of when you know you don't wanna do it anymore, you find someone and you trick them into thinking that it's very much, it's all roses, don't worry about it. It's gonna be a great time and then you hand them the bag of candy. Yes, sir. Steven, everyone. Which release did you start working on OpenSack? That's a great question. Grizzly? I wanna say? Grizzly-ish. Austin. Austin. That tells you how bad I am. He's 23 and he's the oldest. He just looks like old. Thank you. It is true. I think it is a compliment. You got the Obama effect. Wise, wise. Salt and pepper. Any other questions, please don't wait till the end and ask us and come up to the stage and ask us to just go to the mics. So you guys talk about working upstream and from at least my perspective as a contributor, you guys are upstream. So I'm just curious, upstream and downstream seems to be like a relative thing, depending on where you are. Is that the case or are there formal definitions for what's upstream and what's downstream? It's not formal. I, when I got started on OpenSack, I was on a product team working on sort of a distribution product for private cloud and it was really, there were other internal products within the company that were building off of the stuff that we did. So they were funneling their stuff to us and then we were working on it upstream and so we were sort of this pipeline between up and down. Eventually the product that I worked on was End of Life and so then I was mostly like upstream for a year and then it just sort of varies, I guess. So upstream being? Upstream being the majority of your time is spent just working on trunk master code, doing reviews, bug fixing, all of the dirty work kind of stuff. Right, as opposed to productizing or working on product or distro. Yeah, I guess it depends what type of company you work for, if you are a foreign operator. I mean, for instance, in Neutron, Mark McLean, he was the PTL for two cycles but he worked for Yahoo and that's, they don't build a product, they run a cloud. So it depends which role your company is, how they use OpenStack, it can be fluid, right? But as Matt said, I think that you can classify upstream as driving master branch development to the point that that can be easily consumed by operators and users. Basically working on the next release, pretty much. Yeah, yeah. Yeah, so Jim was just saying if you're using Launchpad, which is what we use to look at bugs, if you're looking at that instead of a Jira backlog or a Kanban board or something. Yeah, if you're working more with people from other companies, you're probably upstream. If you're working more with people from your own company, you're probably downstream. Anyway, another question, Jay. Yeah, this is great, thank you. So, I mean, basically as PTL, you need to plan to be upstream basically almost 100%, right? Would you agree with that? Nearly, yeah. Any guidance for how to make your employer aware of that and supportive, especially if they're new to the community? This is recorded. So, let Jay work more upstream, I guess. I'm just, I mean, it's hard. That's when the ugly portion, right? It's hard to convince employers the benefit that they get out of this. It's hard. I think, well, I mean, if you're a media manager or your report chain understands that if you wanna make changes in the community, if you wanna sort of steer direction on features or whatever, if you wanna sort of set priority on things, you need to be visible. And that's like the too fast, too slow thread in the mailing list right now. We keep saying if you wanna make big changes, like you need to get involved and you can't just be like, drive by, this is terrible, see you later. There needs to be some level of trust, I think, and in order to actually properly influence a project. You need to, you can't come in as an unknown, unfortunately. I mean, you could come in and have a very valuable patch and it's great, but to land significant features, there has to be some level of trust that the core team has with you. And the only way to build that trust is to just focus on bugs, patches, code reviews. And to get on the core team, you have to build trust. Well, I'd like to sum it up by saying, if you got into a situation where you got to explain how to be PTL and stay PTL, probably you are already in a bad situation. In the sense that you probably want to figure out the ways we get out of that situation altogether. I'm trying to be a bit extreme here, but being PTL or being an upstream core developer means that that is your day job, day in, day out. And justifying is just with time. We got one more question, because we're over time. Okay, I've got two parts. So some of you look like you might be recent fathers or fathers, or maybe you want to be a recent father. So comment on that along with answering this question. How much did your hourly salary go down when you became PTL? It didn't go down. Your hourly salary. Considering you work so much more, you still get paid the same, you know? Your hourly salary had to go down, dude. Oh, mine went down, I will tell you. So last summer in Barcelona, I walked up to Richard Jones, who was the Horizon PTL at the time. And we had never met before. He's like, hey, you're Steve Maranelli, right? I'm like, yeah, yeah. And he's like, you're the Keystone PTL, yep. And you just got elected to TC, yep. And you just had a kid, right? Your wife just had a kid? Yeah, he's like, do you hate yourself? Like, why are you doing this to yourself? And I wish I knew the answer. That's a great question. When I was new in OpenStack, I thought all of the guys that were mentoring us internally were, they didn't have families or lives. And then I found out like, like when I started Russell Bryant was PTL, and a year later I found out that he was actually married. And it was like, oh my God, Dan's got a wife and Sean's got a wife. And I was like, hold the cow. Like these guys actually have lives and families. You really learn how to like value every minute of your day. And that goes into the personal growth part. Like you have to become good at time management, especially when you have to balance it with life. And that's one of the outcomes of being a PTL. You really learn how to handle that time management. Yeah, disconnect is really important as well. Anyway, speaking of, speaking of, we get an end. All right, thanks for coming everyone.