 Hello there. Good, how are you? Surprised that there are not so many folks here. Yeah. The first minute of the meeting. Give him a few more minutes. I just paged Paris and Josh. Paris is on her way and Josh's meeting is running over. Perfect. I was stuck with the unrelated to this meeting email and I'm surprised that I'm coming back here on the first two on the two here. So let's wait for the folks. Hey, hey. Sorry, I also had a meeting that ran substantially over. I thought Josh was going to be here. That's why I was like, oh, it'll be fine. Like, don't worry about it. I was like, oh, keep going. They were like upset. So I'm like, keep going. Don't worry. I'm going to be like, and then that's really like, I got the pain and I'm like, okay, maybe we need to pint. Hold on. So, so sorry about that at all. Um, it's actually kind of perfect for me because I was wrapping up something that I was working on that I needed to finish before this meeting. And my, that extra five minutes was exactly what I needed. I just had a call with me to say. Um, what I'll paste. Agenda in chat. Cool. And we're already recording because cncf is awesome. And. Well, it looks like it's just four of us hanging out today. That's cool. Um, I'm Paris. 30th all day, at least on the Pacific coast. I don't think we have too much on the agenda today outside of working group updates and potentially dropping formal health check from the charter as a discussion topic. If anybody else has other discussion topics, feel free to drop them in. But that's pretty much it. Josh, do you have anything else to add to the agenda? I'm looking at the agenda right now. Weren't we going to discuss dropping the health check stuff from the charter? Yeah, I said that. Is there anything else? Okay. All right. So, Josh, why don't you go first with governance? What's up with governance? At this point, it's all just work on both the advisories, mostly on advice for building governance for projects. There hasn't been any movement in the TOC on any of the sort of pending requirements issues, mostly because Liz Rice has been unavailable and they shelved all of that stuff while she's gone, which is fine, frankly. Do we, I don't know, this is where I'm confused. Any time we give them guidance, should we like ask for feedback or should we just wait for them from here on out? Well, the main thing pending right now is, what's his name? Minatic. Alexis. Made this proposal for this steering committee workaround for the multi-organizational requirement. We advised against it because after a bunch of discussion, we realized that it didn't actually solve any problems that we had, and in the meantime would add a whole bunch of paperwork to some projects. At that point, it's kind of done, right? We're a working group. We can send our advice to the TOC and they can take that advice or they can choose to disregard it. So, and they haven't had any discussion on it. So, yes, our takeaway there is just to always wait for TOC. Yes, yeah. The, I mean, the TOC has all of the decision-making power for anything that is not purely documentation, right? We can write as much documentation we want about how to create good governance, but if it comes to touching the actual requirements for projects, what we do is we send advice to the TOC and then they vote on it, or they don't. Any other governance updates? Don, how you doing with your stuff? Good. I worked some on the doc and then we talked about it in the last governance meeting, and I think that Josh had a bit that he was going to add. Jennifer had a bit that she was going to add. So, I think as soon as those bits are added, we can do some cleanup and then PR it in, at least as a draft to get some additional feedback. Awesome. You are your work, what are you working on these days? Not so much related to this thing. I'm a bit here to be updated what you're working on. That's cool. Yeah, no pressure for me. And then Don, you're also working on some contributor growth stuff too, right? Yeah, I was working on the health metrics, which I have kind of a start at. So, if we if we have some time, maybe we could go over. Yeah, I'm going to put that at the discussion. Yeah, we can put it at the end. It's not important. I want to kind of show you what I have because I'm not, I don't think it's quite in the right direction. And so, I wanted to see if other people agree with me. I think any direction right now is super awesome. That's just nice. I feel, and I just feel like a lot of projects from what I'm hearing anyway are taking a lot of this stuff extremely literally. And they don't know like when they're reading, oh, showing, you know, demonstrating project health period. It's like they want, like a lot of folks are saying, oh, well, what metric should I pull? And it's kind of like, well, it's more about benchmarking. You know, it's more about like watching you, you know what I mean? Like, yeah, because I well, let's talk about the end. Let's show you what I have because and this is why I think that what I have right now isn't the right approach. I don't think that it does that. And I can easily change it so that it is the right approach. But I want to validate because the more I looked at it, the more I was like, anyways, we'll get there. And then I know that we now both for governance as well as contributor growth have the tracking issues, which is cool. I'm linking to the governance one right now in the in the notes. Should we take the tracking issues? Josh is kind of directed at you. Should we take that and break that down into individual issues that we referenced from the tracking issue? I thought about doing that earlier this week and that I didn't want to I didn't want to create like the 10 issues. Yeah, we actually talked about that at the last governance meeting, we just didn't get around to doing it. Okay, so if you have time to do it, please do it. Okay. If I get time tomorrow, I'll do that. So you're going to break down the tracking issue and those smaller issues. Yeah. That way we can assign it to people and mark them done and it makes it easier, I think. Okay. All right. And then let's see what else do we have here? Charter changes are done and over with closing this issue. I'm looking through issues and stuff right now. It looks like that's it for governance and contributor growth. Contributor growth, like I mentioned, it has the tracking guide and they're working on the contributors template, contributor ladder template, recruiting playbook, potentially issue templates and all kinds of fun stuff. So I make it looks like probably next quarter, we can see a decent size project template repo, which will be cool. Next is maintainer circle. And that's me and I just don't feel like talking right now. The only thing going on with maintainer circle is that we still have intentions of launching some kind of birds of a feather. As the first one at some point in September, TVD, if you've noticed an uptick in people joining our Slack channel and people joining the maintainer circle channel, it's because I've been doing a ton of outreach. I don't know if you've seen me in Slack channels and stuff like that, but I've been going to community meetings, joining Slack channels. I can't believe we kind of have to do this, but here we are kind of thing. So I'm trying to just brew more people interested about maintainer circle and us in general, so that we can just get more people to kind of like help us move things along here. The one issue that I linked in the docs that I was curious about and getting some discussion points on is creating an actual maintainer's site on the CNCF page. Because right now, if you go to maintainers.cncf.io, you get a public spreadsheet of people that can vote for TOC members. So I was thinking if we could actually create this as a page for maintainers, we could link to like all of our documentation, like that would help them, the maintainer's circle events, like all of the like intros and deep dives to KubeCon. I was thinking like of actually creating the community here. So I wanted to see what y'all thought about that. And if it's something that's worthwhile, I'll put together a little bit more of a proposal and then potentially recruit people to help us build it out and talk to CNCF and EOR. I wanted to get your take to from CNCF's side on kind of building that out and if CNCF would be receptive and blah, blah, blah, blah. So I'm going to stop talking. Can we use the contributors circle also for the same purpose? So if you go to contributors.cncf.io, to contribute that CNCF.io, you are directed to our Contribute GitHub repo. And so probably we can reuse this triple for the same purpose as Goli. What do you think about it? I feel like they just need like, it would be cool if they were actual sites and people could interact with them. But you know, I'm not great at building sites. So yeah, I don't know. I guess I just don't know really what a good next step here would be. Obviously we can do some proposal writing and write out what we would want on the site and then potentially recruit some contributors for it. Is the CNCF site is on, hold on, I'm looking on, is it on GitHub? Meaning like for instance, if we got somebody to like just do that, do the page for us, could they just check it into the CNCF repository somewhere or is that private? So right now it's on what process is in them. But we are in process of migrating to the GitHub part, the core basis here. Okay, because I guess I'm just saying it's like, should we petition CNCF for like contracting funds or should we be able to get like a contributor? What do you think? I would say that your first step in any case would be from the trace desktop, we have this request desk. So this is like, it's the best way to put the visibility of this request to the CNCF stuff. Okay, and that's fine. I can do that too. I was really just the first kind of thing I wanted to do was raise it with you all and see what thoughts were here. Dawn and Josh, what about you with creating some kind of online community, if you will, for maintainers slash and or contributors? I mean, I would see it as being part of the same thing. But yeah, I mean, like, for example, all this documentation that we're putting together about how to build governance, that needs to go on some kind of an official CNCF page somewhere. Okay, all right, so let's go ahead and prove by everyone who needs to approve it. Let's go ahead. I do think we want to be haven't looked at those links, but I do think we want to be careful about creating too many additional community elements, though, because it then it becomes like one additional community that people feel like they have to be engaged in, and it becomes too much for people. Yeah, I second that, that's actually the reason why I propose to reuse one of our existing assets, like contribute.cntc.io instead of create and something new. Yeah, more it's I want, I want to have some of our, you know, the completed and approved by the TOC, etc. documentation going on a web page rather than staying in GitHub, because that's an easy way for maintainers to differentiate between the things that are drafts and the things that are actually official. Yeah, I mean, so contribute.cntcf.io exists, but so does maintainers.cntcf.io, like they both exist, except one points to a spreadsheet and one points to a GitHub repo. Right, I feel like even if we did the maintain, I would still want the maintainers to redirect to contribute, because I don't, I think like there's no point in publicly sharing a spreadsheet as a URL. There is a point, so drop, whereas reasons why people might be interested in this spreadsheet, so. Well, I'm saying we can still link it, so go ahead, Dr. Yeah, yeah, yeah. So, but like having having this simplified URL, like regular URL is readable, is a best way to share it, not just link, like this extremely long URL that is auto-generated by Google, Google Sheets. So that's why we're creating this short URL, it can be distributed anywhere. For example, we have, like in our, in the, in the cntcf service that the communication willing that this URL mentioned and who are the people who have an access to the cntcf service desk. That's one example. Well, I will file a service desk ticket. Is the problem is too, are my service desk tickets still being filed against Kubernetes? That's a good point. I wish Anne could be here, so we could discuss things. And it's like, what is this, Paris? Yeah, I didn't know, yeah, I didn't know, like, what are the, what are our current policies with, you know, like, allowing sync, sync chairs, the cntcf sync chairs to file tickets and so should be able to, at least here as a person who has access to it, should be able to, but it's better to double check with them and I'll do it. So just how to, how to file the tickets properly and become a cntcf sync. Well, I'll go ahead and write a longer proposal that has some more of like a mock-up of information that we would like to see and things like that and then start a service desk ticket and start talking to folks. Cool, that makes sense. Also the service desk ticket is required in terms of if you'll need some extra funding for building the website, building the page, so people feel so necessary also for their trading purposes. Okay, cool. That's really it, I think, for maintainer circle. Just got just doing tons of outreach, general outreach, and getting a lot of good things back. Most, the problem is most of the good things are Tommy won the first meeting is instead of you necessarily like suggestions, comments, feedback, which is, which is to be expected, honestly. Anyone else have any other working group updates before we move on to discussion to talk about charter project metrics and the other issue that's in there? All right, so discussion right now in the charter, we had a bullet that talked about performing health checks for projects that graduation to talk about their community and things along those lines. I had initially when we when I went in to do the charter updates for Jared and everything else and trying to get the bootstrap information out of there, I did remove that. Honestly, I don't know why I initially did. I think there was just something in me that was like, we don't do this. And I just kind of scratched it off. And then that's when Josh was like, wait, and then I'm like, wait, yeah, you're right. So let me bring up the charter and Josh, what were your initial thoughts? And then I guess maybe like evolved thoughts after that when you were like, wait, no, I mean, I understood why you moved it because currently nobody's actually working on it. And second, it doesn't seem to be a thing that TOC actually wants us to do. It originally went into our charter because of a request from Chris A, I believe. But even he has not followed up on it since then. So I feel like it's something that we could do as part of community growth, you know, or as part as part of the WGs, like it's something the WGs could actually work on if they wanted to, but it doesn't need to be in our charter, because if it's in our charter, it becomes something we have to do and something we have to report that we're working on. And so I think it made sense to remove it. I just felt like there had to be some official discussion of removing it from the charter before we actually did it. Yeah. I mean, I could move it to the, there is an area that's like future stuff, please help us. We want to grow in this area. So I could move it to there. Don or Eore, did you have any thoughts about that? Whoops, that was on me. No, I just got distracted by a text message. And so I wasn't paying attention. I'll just do that up front. And that's, that's fine too. This was just, I don't know. I think, I think it's safe, I think it's safe to at least bump it to the road map section at this point. Matt and Todd might kill me though, considering they just reviewed the charter. Sorry if you're listening to this, y'all. So all right, that's just, we'll do that, but it's low priority. So if it gets, if it doesn't get done until the next meeting, then so be it. And I'll also make that known to TOC too. All right. Drop. All right, Don, tell us about project metrics. Yeah. So let me share, I'll share my screen, you can see. So, so I started this, I started the doc and someone added kind of who, what, when sections. And then I started diving into the project health table for dev stats. And so I basically, what I did was I took the stuff that was in dev stats and was just like, here's how you map it to who, what, when contributors, companies, maintainers, commits, things like that. So this is like, this is very tactical and very tied to the project health dashboard. This did help me hang on one second, Josh, this did help me sort of understand kind of what, what we have from a data perspective. But I think that this is completely the wrong approach. And I suspect that it should probably look something more like this. So here are the things you need to think about. This is why it's important. Here are some examples of the metrics that you could use to measure this. Because what I have right now is, so this is sort of kind of framing it in why it's important. And then here are the things. This is the opposite way. It was like, here's a big list of the things. And then I can start going into why things are important, which I started to do kind of in here. So like how you would interpret it. But I feel like this is, I feel like this approach is, is too much detail. And I think people are going to get bogged down in it. And I'd rather have something more high level that gets people thinking about it the right way. And then Josh, you had a comment, I just wanted to get through my, my pitch before. Yeah, well, I would say a second reason why the first approach is wrong is that those metrics from the dashboard are almost universally wrong. Good to know. All right. Yeah, because the more, the more I started working on it from this approach, the more I was like, I'm not comfortable with this approach at all, but I've done enough on it that I'm going to show it to people and see if other people are as uncomfortable as I am. I started digging into specifically the, you know, contributions by largest contributor stat there, which is the multi org stat. And the numbers I was seeing for projects I work with regularly were at odds with reality. Okay. And I started delving into it and I literally could not get those numbers to mean anything at all. And Lucas has been dodging me in terms of responding as to where those numbers actually come from. Okay. So are you saying here's Josh? What are these and issues? I have not raised it's an official CNCF ticket about it. And I think that would be the next step, but I wanted to actually discuss it this meeting. I mean, it may just be because Lucas is busy on some other project that Chris has assigned him to, but I have not, unlike the Kubernetes dev stats, right, there's no thing at the bottom explaining where the data comes from. And so I'm like, what is this measuring? And I've been back and forth with Lucas about it on Slack a couple of times and he keeps putting me off the issues. Like I know this is technically the wrong, I know we're saying like it's the wrong approach. I would actually use these as examples, possibly use these as examples and the other approach. So the idea would be that you would say something like time to first response is important because of these things. And then, and then you could say that, you know, dev stats calls this this, you know, this might be where you look for it. Yes. Yeah. Yeah. I still, I personally, I mean, I personally, I wouldn't label that as the wrong, I would just say that like what you're saying is like they should have like a high level at first, like a premium and and then dig deeper. Um, but yeah, it's just, it's just kind of flipping it, sort of flipping it upside down. Yeah. But I've never actually like seen it go that deep before and somebody that actually does go deep in data like that, I appreciated that. So that's why when I saw it, I was like, wow, I appreciate this. No, I get, I get what you're saying too with other projects that might not think like me. So yeah, and this is something we struggle with inside of VMware as well. Like I have a very simple set of project health metrics that I put on dashboards that we use for, for everybody because we have, you know, we have hundreds of projects that have a significant enough number of commits that you can run project health data on them. But not everybody is going to dig into something like a dev stats or a patergia dashboard and just like figure it out for themselves. It has to be, it has to be easier. People won't use it. And then if they get interested, then they can dig into more data power to them. You should actually raise that on here. Did you write that on here at the very top? Like, because that's honestly a really good piece of advice. It's like, you might not want to dig into this. And here's why. Don, thank you so much for your help with this. Well, I'll take this feedback and then I'll, I'll just flip it upside down and rewrite it so that it's more focused on kind of the, the reasoning. And I'll add something about how it should be easy. Don, I have a bug report here. Um, your name is not listed as Dr. Don Foster. What the hell? It should be. It should be. The hell is this? Fix it. Are you, are you, is it official? The doctors, the doctors? Oh yeah. I got my doctorate in, it became official in 2018. Really? See? Bug report. I, yeah, I finished my PhD. No idea why. I thought you were still just doing, you were still in the PhD waves. Nope. I did it. I, I powered through. I did it in three and a half years. Well, you're officially Dr. Foster from here on out. I am. The doctor. Thank you, Amy. By the way. Yeah. That's how it was late. It was the important, the important facts. Um, you know, we can raise this on the next TOC update too and give you some shouts, Don. So I think once the next TOC update is that Tuesday? That is Tuesday and your slides are due. Yeah, I know. So I'm like, we need to so Don, you're going to lend us the project. Yeah. So many, some of which have uncriticed slide to talk about project health. I will go ahead and add you to those slides. Super. Um, and then that's really it, I think for us today. Oh, actually, no, I'm sorry, there was just one more discussion point. Does anybody have your, do you have any? I'm sorry, I'll stop sharing so that you could take back over. No, that's fine. Eeyore, do you have anything for Don, Josh, anybody else with project health stuff? I think a lot like this by Eeyore. Oh, I just realized we actually have a major thing to discuss on the agenda. So that I forgot about because Dimms is not on this call. Dimms had a proposal for badging. So let me add that to the bottom discussion. I added it just at the link for me. Well, I'll breeze through this one. And I'll share my screen. Just not much to share. This, we've talked about this a couple times. This is the, should we add some kind of graduation guidance for, well, not graduate, should we add some kind of guidance for graduated or project going to graduation? There we go. Words are hard. And as it relates to how they take care of their people. So it's kind of like governance. We're not prescribing a model. We're just saying have one. So whether that's a SIG for contributor experience or community experience or developer relations or having a full-time community manager, having a part-time community manager, being explicit with what CNCF does with your community, like that kind of like, I guess, is kind of where I'm going with this. We've talked about this in a number of different avenues. So this is just a discussion topic that I wanted to pop on and see if anybody A is interested in helping with this, number one. And then number two, what kind of like general thoughts there are around this, or if you're plus one, negative one are neutral? I think this is something that's definitely good to have. I think a lot of people, I think there are two sets of people. There are people who completely underestimate the amount of work that it takes to do community management for a project. And then there are the people who try to over-engineer the community management for the project and end up with a bunch of stuff that they don't need. So I think some guidance about how all of that works would probably be helpful. Yep. Anybody think that this is a terrible idea? We should not proceed, go away. Nope. On a previous discussion, I even spoke up on that at some point we might want to propose this as a requirement for graduated projects. Yeah. Yeah. Yeah. Yeah. Yeah. This says guidance and graduation kind of, I think like it could potentially go hand in hand. So all right. Well, that wasn't much of a discussion. So let's move to, let's move to badge. Well, I guess it wasn't much of a like a heated debate rather. Let's move on to Dim's's badging. So we can talk about that because that was a really good proposal. Don't move. I'm going back. Here we go. Oh, I didn't. Josh, should you find the link? All right, cool. I'll share my screen. There we go. Finally found the link. Okay. So basically, Dim said this great proposal that we would take the things that are in requirements in the annual review in the due diligence check. And for things that are sufficiently atomic, we would actually create badges around those things. And those badges would get added to the project page on the CNCF page. So there would be a badge for what your maturity level was. There would be a badge for whether or not, you know, you were considered multi-org by the CNCF. We were sort of throwing out other ideas. Dim's was actually going to go back and take a look at the annual review to see which other items we could potentially create badges out of. The main reasons for doing this is the CNCF does a lot of sort of examination review of projects. But for users and potential contributors, that information is not very transparent. It is actually hard to find and hard to understand. Whereas a badge system would be a lot clearer, the second, you know, and we already use a badge system for security with the CIA project. So this would be on the same sort of principle. And other ideas for badges I threw out was things like, does the project have some kind of contributor onboarding or not, right? You know, these sorts of things. So we had this discussion. We were very much in favor of it. We were putting together potentially a proposal to make to the mailing list here and then from there to the TOC when we ran into a major problem, which is because of the increase in the number of sandbox projects, in parallel, the TOC is proposing to stop auditing annual reviews. This means that the annual review would become entirely self-reporting by the project. And that would make it difficult to base badges on it. Because, you know, if somebody has an OKR that their project needs to get x-badge, they're going to cook the books on the annual review. I feel like if we did have good data, we could automate that from those dots, right? Yeah. Although, I mean, you think about it, for example, like say we wanted to have a badge does this project have contributor onboarding? The thing is, there's like four or five different ways you could have contributor onboarding. All of which are equally valid, if you follow me. Couldn't they be community managed and community enforced? I mean, the community itself will know that they're bullshitting. Excuse my French, right? Like, I mean, there's not too many people in the Kubernetes community who are shy about calling bullshit when, like, there's bullshit. You know what I mean? Like, I guess that's what I take there. Like, they can rock the badge, right? But like, if somebody in their community eventually calls BS and like the TOC or somebody, right, is going to hear like, hear about it, I guess. So that does bring up another point that we actually discussed and wanted to bring here, which was whether or not the badging proposal should include a challenge system. My suggestion was that it should, but challenges should first come to the SIG, simply because there will be a lot of spurious challenges. And we only want to forward the legitimate challenges to the TOC. However, I'm also worried that if the only sort of auditing of badges that's being done is via the challenge system, the badging process will start to become seen as excessively negative. If you follow me. Can we just do like a handful of randoms, like some kind of random generator at the end of the year? And it's like, oh, we're gonna just check out these five projects. Yeah. And that's why we're discussing this in this meeting, right? Because now we've realized that a realistic badge proposal means that SIG contributor strategy needs to take on some responsibility for auditing the badges, whether it's spot checks, whether it's brief reviews of the annual reviews, whether it's something else. Yeah, I mean, we can build this in as a role, make sure we always sustain that kind of, I mean, right now we're not necessarily, we're building, we're not necessarily sustaining anything. So I could, I could see us do something like that, thoughts from others. I think we need to make sure that we're prepared to take it on if we decide to, because it is, it is going to be, it is going to be a chunk of work that we're going to have to maintain kind of forever. I guess let's see what that would entail, right? I like this. So like I feel like, especially the, even the other stuff, like in the steering, like imagine if that instead of the same steering, it said like what governance they were, you know, like steering, like, you know, maybe you said TOC, yes, or owners, yes, code owners, yes, or like, you know, like that kind of a, yeah, I like this a lot. I think I want to be able to highlight a scaling issue here. We have, including Kubernetes, 65 projects. I'm just going to leave that here. Yeah, I mean, this, this could be a lot to maintain. That's why I think we want to be sure that it's something that, that we wanted, that we want to sign up for at this point. Also that number is going to go up as of like September, just like guaranteed. Also I'm like, what if, if we make it, if we build it into the already pro-existing processes, number one, and then number two, community moderated and enforced as the first, as the first wrong. And only start with a few, meaning like, you know, the ones we know we need. So we know we need the steering one. Like that's the one, right? Like the, just governance and then, you know, I guess maybe add from there. Yeah, I like the idea of starting small. I mean, I really do think we should start with just a handful of badges. Or just one. Yeah, and see how it goes. Yeah, just this one, like, because we know that this is solving an immediate problem, right? So it looks like the to-dos here. And I'll, I'll just copy them, leave this and put it on the actual agenda too, just so we can highlight that. It looks like, I think April and Dimms were also working on this. I'm working on description of the badges escalation process and badge for active maintainers. Yeah, the, yeah, and that's actually a good example. I mean, one of the things that came up during the discussion, you know, for, for this that I don't think is in dispute is, well, I don't see as being able to automate most of the badges. I do think that every badge should have a very quantitative description because we will get arguments about these. And, and anything that is qualitative will be a source of argument. I mean, I'm also like, I have not, I haven't dug in too far deep into like technical badge systems in my lifetime. So I'm just so curious to know, like, not even outside, like even outside of open source kind of like, what are some of the other ways that communities do badging and stuff like that. I'm curious to hear from some experts. It might be nice to invite one to like, one of our meetings or something like that, to kind of get folks. Yeah, I only know the ones in open source. I mean, so obviously we can talk to the CIA folks. Yeah. The other one I kind of bring in is, is somebody from the Fedora badging program, but that is badging of contributors. Yeah, I would be very interested in hearing from folks. But they have the advantage that their badges are almost entirely automated, which is nice. So I can, I can definitely, um, yeah, let's move your way in on that. Okay. Speakers, guest speakers. Yes. All right. Yeah, I know. See if they would come and talk to us about the, how like, you know, maybe best practices, what they hate, what they wish they didn't do, like all that kind of stuff would be super helpful. All right. Does anybody know, are there any other umbrella foundations that actually have a badging thing? We can ask Twitter. I would have to go look at like, LFN might, sorry, networking might have one. Yeah, I mean, probably hyperledger. So I would start with some delaying foundation, yeah, hyperledger might be good. Josh, Apache doesn't have anything like this, right? Well, that's what I was wondering, actually. Let me ask, let me ask Rich. Yeah. Well, I can ask Rich about, about that. And I can ask Lisa about LFN. So yeah. And if Apache does, guest speaker, guest speaker, thank you. Well, I think that's it for us. That's it for the notes today. Less call for non-alcohol. All right. That's it then. Oh, actually, no, I'm sorry. Josh, review my PR. Get my, get my resources in there. Wait, which, which one? This is not the charter one? Not the charter one. This is just resources.md. That's collecting a bunch of like, links that are beneficial for us to keep track of. I went all grammar police on you on that one. Sorry. What happened? I went all grammar police. Oh, you did? You did it me? I did. I totally nitpicked you. But, but I started to nitpick and then I was like, and just do this for the rest of the doc. And that's fine. I know laterally, it was like 14 days near reviews. I'm just like, someone out there review my PR. You are needed. You are needed. Needed me before you did anyway. Just a little bit. All right, cool. Then I will, I will get, I will go to Don's knits and then you can, then you can approve it. All right. Well, that's it for me today. All right. I miss all of you. It's not like all of my meetings are running now. It's like, I miss seeing everyone. I miss, I miss all of you. Next year. Well, that's like conferences and real hugs. It'll be great. You are, how are you feeling? About what? About being? After accident. Like, how are you feeling? Like, after the? I'm doing okay. And I'm feeling extremely proud for, for the new gigs. All right. Okay. I'll just chop it in on you. Glad, glad you're here with us. Yeah, I'm here. Smiling is always. Yeah. Smiling. I'm glad you're here with us. All right. See y'all. All right. Later.