 Good morning, Josh. Hello, April. Hey, Abby. Hello, friend. Can you hear me? Hold on. Let me check my sound here. That's why. Okay. Here we go. Howdy, everybody. I was just looking at. Hmm. Hello. We can hear you. Ah, there we go. Okay. Um, Okay. Okay. You paste the link in for the minutes. What time is it in? In NZ right now. Um, it is currently eight AM tomorrow. Oh, it's not that bad. This is a, this is a great meeting. Yeah. The, um, yeah. Well, mostly, um, April and I are both West coast. And when we realized we didn't have anybody on the initial list of members who was. Um, I was like, let's hold this one in the afternoon. Yeah. So I pasted in the. Minute stock there in case. Some people don't have it handy. Um, so I first, um, Let's get the formality is out of the way. Um, welcome to the governance working group meeting. Uh, for June 22nd. Um, this is an official, uh, working group of. The C and CF. And therefore we are subject to the C and CF. Code of conduct. Um, this meeting is also being recorded. Um, so don't say anything that, um, You wouldn't want your mother-in-law, the cloud native hacker to read about. Um, the, um, Uh, and then, uh, we can get started. Um, we've got a few things on the agenda. Um, but not. A huge workload. So if you have. Something else, please add it. Heard of just lost April. So hopefully she will rejoin. Where is. Um, so first things here. Um, most of our activity for the last week has been around the maintainer diversity requirement. As it's called. Um, for. Graduated projects. Um, so this is a requirement, uh, for graduated projects that is in the C and CF graduation document. Um, but it's there as kind of a bear sentence that just says. Uh, the project must have committers for more than one company. Um, now this requirement is given projects, various projects, some problems. Um, partly because a lot of its terms are not all that well defined. And so, um, we've taken it on as. Kind of the first requirement to try to give a full work up to. Um, so. Oh, let me add the link to the documentation. Um, and if you actually look at the documentation draft. Um, that has an example of the kind of work up that I'm thinking of for dealing with these requirements for. SIG contributor strategy in the governance working group, right? Which is the ideas to give projects a full framework for understanding the requirement. And how to fulfill it. Um, and part of that has involved going to the TOC and saying, okay. This is your requirement. What do you actually mean by this? What is it you're actually looking for? Because I mean, the truth is, we're not actually looking for two committers from. Different companies. It's more that committers from. Multiple companies shows us certain other things about the project. You know, it shows us that. Um, it's a demonstration of the project is open to. Um, contributions, regardless of employer. Um, or it's a really good indicator of that. Um, I, you know, and that. Um, the governance is not wedded to corporate hierarchy and also gives us some idea of what would happen to the project if something happened to that particular company. Um, it's also honestly a good sign for adoption as well. Right. Because if some. Company that was late to the project liked it enough to put somebody on to working on it full time or half time. Then clearly that means a lot to them. Um, that's a good sign for the project. Um, I think the key was the answer to the primary requirement was that they're looking to demonstrate that the project is open to contributions regardless of. Employer. Um, and well, there are other ways that that could be true. Um, I having maintainers. That don't work for the same employer is the most material requirement. Um, I think it's better to call it a multi employer requirement or a multi group. Yeah. If you look at the draft criterion, I'm suggesting rephrasing it. Which is to say control and maintenance of the project in its code must be shared among more than one organization. Sounds good to me. Cause to be blunt, one of the things we ran into is not all projects use the word maintainer the same. Yep. And we ran into one project where they call every single contributor or maintainer. And we just want to say, look, we don't care what you call them. We just want project leaders that don't all work for the same person. The, um, Now one of the things that this is also suggested and has come up in a discussion with the linker D project. Is that, um, backing this rationale, we might be, you know, we'll be suggesting that it's possible to make a case. For a project. To demonstrate their openness to contributions in other ways. It's just that it would be much harder to do it in other ways. Right. If you've got maintainers from multiple companies, then we don't really need to look at anything else. But if, um, you don't, then we need to look at, okay, how many real contributions came in from outside your company? How were they approved? What's the published approval process? Um, I don't know. All of these are the things to demonstrate that you're still open. Um, the, um, that has not been approved by the TSE at this point. That's a suggestion that I made. Um, the, um, mostly because I think, because we have a lot of projects that are borderline where like, yeah, they have one or two people listed as. Maintainers don't work for the same company, but they're not really active. And, um, and if we look at the intent of the rule, then we can maybe work with projects to fill it in other ways. One of the things that's been within the Kubernetes community, that I've been wondering if there's ways to make available to other CNCF projects is our, um, ladder, uh, uh, for creating the owner's files and those YAML files themselves being a really clear indicator beyond commit, um, but I think it's important that people who have authority, uh, to, um, to be, you know, I suggest that automatically as reviewers and, and to be those who have the, um, authority to approve. And that's it. I don't know. I don't want to push governance on folks, but the accessibility to that infrastructure isn't exactly. Easy at the moment. So, um, um, I think it's a good idea. I mean, so part of our job is a working group is going to be, you know, a working group. Um, not for the side rail too much, but we're, I'm working with some folks on, uh, possibly something like a CNCF infra working group. Um, because of the conformance work we're doing so that some of our tooling can be there. Um, you know, not that it's just as a side note on another possible metric. Um, I think that the working group is going to be to write up a bunch of advice to projects for, Hey, here's how you do these things. And I think writing up the owner's file structure. And, you know, how this is a good way to sort of distribute ownership of code. Instead of saying, Hey, we're going to have this one owner's file in the root of our main repo and that's going to control everything. Um, I think that's a great idea. I would love to own that and take anything. I've heard you on people to talk to who can speak authority to do that. If I were to like interview or chat with them. Uh, Yeah. Yeah. That's super important to me in a way that, um, I think is good advice, not just to CNCF communities, but other other communities as well. I like the inclusion of engenders. Um, Should I? How do we capture that? Just created. Um, I'm adding it to the notes right now. Beautiful. Thank you. The, um, Yeah. You know, and obviously not, not everybody's going to solve it that way, but it's one way to solve it, right? Because then you can just compile it and you can say, Hey, I have this list of people who don't work for the main company who own these bits of code. You know, the, um, I like that you're phrasing it as suggestions and advice, not as, um, Yeah. The way. Yep. Um, cool. Anything else on. Yeah. So, um, in terms of future from this, I'm going to continue working with the TOC. To, um, Refine the maintainer diversity requirement that's currently rather a long discussion happening on the issue. So, um, although I think it's worth noting that the one person posting the most on that. A thread is not on the current TOC, not on any current SIGs and not actually the leader of any current CNCF projects. So, um, just, just for a sense of perspective. Uh, that's, that's Alexis, he was on the first TOC that we had. Um, but he's not currently. So yeah, and it is, it is problematic to use the term diversity when we're only talking about, um, diversity of employer. I, it's also been, it also, it's been a long time since I've been talking about diversity. Smacks me in the nose every time we discuss it with the fact that the CNCF has no official other diversity requirements. Here. Here. Um, the, um, which is one of those things that I think we're going to sneak in via advice. Um, as in we can write a bunch of advice about improving contributor diversity. In terms of much more than employer. Um, but, um, getting the CNCF to adopt those is going to be a real challenge. The, um, which we should eventually. I understand this is a lot of different folks involved. What, what do you think the challenges would be in that regard? And how. Um, Honestly, that so many projects are so, so far from being like really anywhere. Like really anywhere with that. Like I would say, aside from Kubernetes, most of the CNCF projects. Um, the standard CNCF project has one or two Chinese or Indian contributors. Um, no women contributing. Nobody from any other non-white group. Um, impossible for me to evaluate obviously gender presentation, sexual orientation or disability. Um, just based off of people's names, but with the projects that I've been working with. Let's just say if we were going across the board with CNCF projects and doing. General diversity scorecards. Um, most of the projects would be getting a D minus. So, um, taking it on is going to mean a major CNCF wide effort. Um, which means I don't want to throw it in casually with a list of other things. I'm also not certain that it is. Would be under governance working group. I think this would be more contributor growth or general contrib strat. Yeah. We plan on working on something. Yeah. I mean, one of the things that's recently come up is that. The diversity picture. Aside from employer diversity. Um, I think it's going to be a great opportunity for the CNCF six is pretty dismal. Something that I noticed by the way. Um, it seems like the groups with the most, um, maintainer. Um, variety with vendors and organizations are the ones that have either community managers or community groups. Um, I think it's going to be a great opportunity for the CNCF six is where that growth can happen. And it's not a afterthought. And I think that is the difference. I almost wonder if we should put a graduation requirement. That you have someone taking care of you. And not just a someone, but people. And I think that's the difference. Um, I think it's going to be a great opportunity for the CNCF six is responsible for this. Who owns this. And it's not just a, like, Oh, look at all these people who own different parts of the code base. It's who actually owns the operation of these things. Who is going to like, you know, and a lot of their cases, what you're seeing too, like, even with NACS, like, Maybe they should form a steering committee. And, and or people. Assigned. Okay. And that is something that we would actually approach through governance requirements for that matter, because. One of the parts we'll get down to in a later item is. That. There's a requirement that the project have governance. Yep. But materially, all that's in there is that it has to have a governance. WD file and that file must have words in it. Yeah. And I think the requirements should be much more robust. And I think the idea of saying, Hey. To reach the graduated level, a project must have. Meta management, right? Must have something beyond just code management. Whether that's a professional community organizer, a steering committee or whatever. We could totally put that in the, in the, you know, this is what graduated governance looks like. I mean, we might get pushed back on that, but. It won't happen if we don't ask for it. I'm keen. Governance does go. We're talking about governing. The humans. And in a way that. Allows us to collaborate on something that is the, that a shared output of those humans. And to not have. Some humans whose soul focus is the humans. And the health. And the connection. And the collaboration of that. It seems. As a, as a, as a large missing piece to the puzzle. In the way that we govern ourselves. I am definitely on board. I'm not going to lie to you. I'm just going to say that. Putting a proposal forth. To the POC. The graduation requirements include. Humans focused on humans. Preach. I actually liked that line. I'm not going to lie to you. Because it's just like, and like. You know what it's talking about. You know what I mean? Cause I was sitting here like staring at the wall, thinking of something clever. But I was like, that's it. I like to call things what they are with extremely accurate names. Yeah, I like that. Well, that was why I said. My core definition of governance is. The definition. Of. Who does what and gets what. And how. The, um. And, um. Yeah. Okay. Um, that sounds good. Anything more about. Um, the, um, poorly named maintain your diversity or, um, multi-organizational leadership, which would be a better name for it. Um, Loving the name change. Yeah. We want to try to ensure that we capture this. This need for the government structure change. Yeah. Is either an AI or a thing. I don't know. I do want to be a part of that. But I can offer my. Okay. Okay. Uh, we will. A little bit further down the agenda for today. Cool. Um, one of the other things I wanted to say is so. Um, Uh, one of the other things that's kind of fallen, um, into our lap is. Um, one of the other things that's kind of fallen, um, into our lap is. The end user requirement. Now this isn't honestly strictly speaking a governance requirement. Um, but it's ended up in governance working group because there is no other clear place to put it right now. Um, and it is a project requirement and. Um, it is a project requirement. Um, it is a project requirement. Um, and probably it was because April actually cares a lot about it for gRPC. Um, the, um, so. Um, the. Um, So it ended up with us and I don't mind it being with us. At some point, I could imagine it being shifted over to a different working group or a different SIG. Um, it's, it's easy for me to come to the TOC with a laundry list of saying, Hey, here's the requirements that projects are not understanding. Um, because for the end user requirement, the big discussion was. Does the TOC care more about demonstrating adoption of the project. Outside of its initial vendor and partner ecosystem. Um, or are they caring more about building up the end user council? Um, because those two things can have a different definition of who is an end user. You follow me. The end user council is specifically companies that are not in any way cloud vendors. Whereas if you take a more general definition of end user, a company that is a cloud vendor in one context can be an end user of another product that they don't work on at all. Um, so. Um, this has been a material question for several projects that are currently, um, trying to get any incubation. Where they have a bunch of adoption. But it's among companies that are cloud vendors in some way, even if they don't contribute to the project. Um, so. Um, the, um, and that includes cloud native build packs. And, um, cloud events actually. Um, so. So we're looking at, you know, what's the definition of this for. What does this really mean in terms of these projects getting accepted and then coming up with again, a. A structure for the SIGs who are evaluating projects. And saying, you know, hey, do they actually meet this requirement or not? Um, I think we need to ask for some clarity, Josh, on the end user requirements as they stand, does it require defining that or does it require having a list? Uh, from the project, it requires having a list. Gotcha. Um, basically, I mean. This is one of the, the, the. The current TOC chose is what I call, um, avoiding Corba. Did you ever do C plus plus? I know, I know Corba from many different languages. C plus plus. Yeah. So if you remember the object management group used to get together twice a year. And every meeting, they would define 50 different standards. For code structures that were never used by anyone. Um, And no one wants to repeat that. Um, so the, um, And, and that's what the TOC chose is the primary reason for this requirement. Um, which from my perspective is good because it gives projects a fair amount of flexibility in terms of building up their end user list. Yeah. Are we trying to get clarity on an updated reason for the TOC to have this list? They've already given us clarity. That's the update I'm giving for the agenda. And so now I'm working on a draft. That will be, So part of my vision for the requirements that they currently have, right? So currently for the requirements, they have a long document called requirements in each document. It has this really short section that lists out the requirements for each level. A lot of these requirements are very short sentences. They're really not explained. And so my vision for that for at least the ones that overlap governance in some way is, um, And, you know, I would like to see the same thing with contributor growth, right? Is that for each of those requirements, we then have a, it links to a document. And that document explains at much greater length, what the requirement actually means. Along with advice on how the project can fulfill the requirement. You know, as in, Hey, you have to have end users. Here's a bunch of advice on how you make contact with your end users and how you get them to go on the record. As being end users. Cause that currently does not exist within the CNCF. The, um, so. Yeah. I mean, the end user one is not nearly as troublesome as the diversity one for whatever reason. I think it's maybe because it's not as hard. I wonder in the past. I've been dealing with, uh, particularly for conformance. That's the area I come into it. Um, uh, people. The reason for that being. Um, less about adoption. And user council and more about the. Where they come in on the, the, um, the joining scale or whatever, like, the, the, the, how to buy a ticket to the show. So to speak. And I just. Want to put that up as an acknowledgement of the pattern I've seen as far as people self-selecting. Uh, you know, Are they either, or, or, or not. And sometimes pushing back on that, depending on some more subtle things. I think this will provide some clarity around that. I appreciate it. The mind you, Cheryl was not in that conversation, so I still want to sync up with her on it, because she may have a very different opinion on whether or not the end user council and user committee, what is the end user group called? I know it's EUC, but I don't remember what the C stands for. Committee, I think. Yeah. Community, community. No, it's community. Community, community. How strong of a, because the main thing is we still do want projects to help recruit end users, their end users for the end user community. So it's not like we're dismissing that. The question is whether or not them having done so should be a requirement or a request. The, so, given that, I started writing on an outline and I haven't gone beyond the Google Doc stage in this because I've been able to sync up with April on it or anyone else, partly because of a lot of other things going on, which is to say, okay, the main product of this working group is going to be honestly a bunch of documents. Well, documents and interactive advice. We've already started on the interactive advice because having announced contributor strategy projects are coming to us and some of them have governance problems and they end up here. But we also need to produce a whole bunch of documents and so I was trying to construct sort of an outline of the documents we need to produce. What is our checklist of documents we need to produce? And I see it's falling into two areas with interlinking between them. One is backing documentation that's related to governance requirements, what the CNCF expects projects to do in terms of governance requirements. I mean, as an example for that, we say, hey, to get into the sandbox, a project has to adopt the CNCF code of conduct and the CNCF's IP policy. We don't supply anywhere any helpful information for how a project materially does this. And so that's sort of what's needed in document. Like, hey, here's some suggested steps on how you would adopt these, here's what these requirements mean and here's some suggested steps on how you would do these things. One of the things that doesn't really exist at all now that the TOC is interested in and I would like to produce is basically, construct these sort of two tiers of required governance. So this is how much governance we expect an incubating project to have and what they materially need to have to fulfill that level of governance. And this is how much governance we expect a graduated project to have and this is what they need. Here's the checklist of things that they need to fulfill that requirement. And that could include things like, on the graduated level, things like, hey, you must have a person or people or a council that is responsible for looking after the humans in your project and not just code. And then the second half of this would be a body of just sort of general advice of four projects developing governance. So, you know, like, and this particular set of advisory documents has got a really large overlap with contributor growth to the point where I think we're just gonna, it's gonna be a lot easier to work on the same documents and co-edit them. Because like, you know, I say from a governance perspective, you have to have a document outlining who is a contributor, but that who is a contributor document also needs to have a bunch of contributor growth stuff in it as well, not just, you know, a definition of here's the requirements for being a contributor. You know, and then examples of different governance structures that a project may have and how to actually implement them and, you know, other things like, hey, how do I recruit diverse leadership for my project? The, a couple of things I'm not real sure about in here are release process, whether or not we feel like that falls under this or not. I mean, because I, it's not currently a CNCF, TOC requirement or that sort of thing, but I kind of feel like a mature project needs to have a documented release process. Among other things, my personal experience has been with projects that do not have a documented release process, the release process becomes a place for bad actors to subvert the project, or for well-meaning contributors to get completely stonewalled. The, but I'm not sure about that. I'm also not sure about where, I kind of think SIG security needs to be in charge of any security issue handling, et cetera, that projects have. There actually is a requirement in right now about security for graduated projects, meeting the, whatever it is, best practices guide, which is another Linux foundation thing. And there are things in there about security issue handling and that sort of thing. But again, we're not providing project with any advice on how to create that. So that's kind of, that's what I had started out with the outline. I could really, really use some feedback and additions and stuff to this outline before I turned it into a checklist on an issue and say, okay, let's hammer these out. To make sure I'm tying things together correctly, Josh, I'm going through the bullet points that existed when I started adding notes and updated on maintain a requirement, diversity and doc draft. And then I started adding things under update end user requirements. But I'm unsure if that was part of the work outline for working your documentation link further. No, work outlines the next item, but it doesn't matter. Where is this update on end user requirements document that you're referring to then? Or is this? Ah, okay. Hold on. I think that is just an issue. There is no document at this point. So let me link the issue. There we go. Thank you. Gonna move this all down under the other agenda item. So take a look at that outline and see if you have any thoughts on where we should go for it. I mean, not necessarily now, but. I noticed that our friend is an April. Yeah. And I wanted to make sure that if she wanted to be a part that she knows we're still here. I don't know if there was a drop. Yeah. I don't know what her candle is, but if we wanted to make sure she wasn't moving. Yeah, I pinged her runs on Slack. I don't know what's going on. No stress. Yeah. Cause she said she was gonna be at this meeting and she was at the beginning and then she disappeared. So. Being sure the invitation is clear. I had texted her and said that I scared her off and she said she's having an issue with Zoom. It's a Zoom thing. Okay. Or a computer thing or something. Good. Yeah. Okay. One of the other things that I wanted to just bring up for this committee, and we're not necessarily gonna do a lot about it initially is that currently one of the things that the SIGS and the TOC consult is this CNCF health chart, which is a bunch of stats based off of the DevStats model that Lucas put together for the CNCF. Very pretty. It's very pretty, but it is very hard to get any of those stats to correspond to any kind of reality. Okay. Because like I've been working directly with a couple of projects that, for example, are having trouble with the maintainer diversity requirement. And yet if you look at it in the CNCF stats, like one of them shows that the founding company is only responsible for 55% of contributions. But then if you go and get hub and you look at any of the individual repositories in that project and you look at the last 200 commits, 195 of them are from employees of that company. So there's something about how those stats are being collected that is resulting in some potentially misleading numbers. So I've brought that up with Lucas. He's swamped with some, he's been swamped with something else from the last week, but I'll be investigating exactly that. That aside, one of the other things that Chris A has requested from us is that at some point, contributor strategy is a whole, so looking at the various areas. I go over that health chart and basically suggest what we really should be looking at because honestly that chart was put together in the basis of here's two dozen statistics that we can easily obtain. Rather than, hey, here's the 20 things that matter most when evaluating the maturity of a project. Prioritizing the visibility of those questions and then making sure that the answers we're seeing are accurate reflections of reality would be a nice, I would say, in the way that we're looking for a cadence from our projects, it would be great for the release cycle. It might be good to get a health update rather than, and it's something that's curated by a human that goes through and checks on the health of these things in a meaningful way. And maybe, because there's many things, I don't know, this is a thought, we're talking about the health of these. And then we're saying we were talking about the graduation criteria, including humans caring for the humans in that area. It might be good for a human to check in on the health of those communities as a whole and give a report on these are the things we've noticed that you would never notice unless you cared to talk to them. Yeah, currently, by the way, that is something that CNCF committees and staff are supposed to be doing for projects as there's supposed to be this annual review process. I'm not clear on how much that happens in reality. It would be cool to see it like ASF style, like what we're trying to embed in Kubernetes itself, you know, from an annual report perspective. Baris, I'm not here with the ASF model in regard to speaking to you. No, so Apache Software Foundation has an annual reporting structure for their projects, where their PMCs, which is like their chairs in Kubernetes, except for they can actually flip the bits. And they have to report in on project health quote, quote. And Apache Software Foundation determined it's like a list of X number of questions that helps them determine like what project health looks like for their projects. And then they like host them online and do like a big deal about it. So like if you wanted to go see like what Tom Katz's annual report from last year was, you could go and see it, like how many number of contributors they have, kind of like a curated dev stats, I guess, almost, but not necessarily like dev stats or like a report. But, and that really forces those communities too to talk about project health, which is something that we really wanted to do when steering on the Kubernetes side, which is while they're completing these reports, they're gonna have to talk to their communities about them, right, so that like gives that forcing function of, oh, let's talk about these things today. And, you know, not necessarily not. So, wondering if we could help out there from our group, trying to think of how, or especially programmatically anyway. Probably, and actually honestly, looking at the annual review as more of a participatory exercise where the project participates in helping prepare it, I think would help make them actually get done because currently it's kind of up to say, SIG committee members and the CNCF staff, all of whom are kind of overloaded considering the number of projects that are out there. All right, really like where you're going, Josh, with providing advice and suggestions. I wonder if we could take it a step further with offering times to help get those things across the line of people who can mentor in those areas that we're requiring. And I know that's the CNCF's overall role, but I wonder if there's not a way to make those help, you know, the being able to raise the hand and say, I need it and having that connection time available is similar to, and maybe modeling that in our other communities as well, with what we know are one-on-one mentoring hours or find some way where mentoring is a heavier part of modeling the behavior we want to see by defining it really well in suggested areas without it being a requirement of them, more of an invitation to do it with all of the help that they would want, should they say, yes, I would like to do it in that way, can you help me? Sorry, we're trying to find a way to concise this down into actionable, roles and helping and moving forward. Well, Paris already had a couple of things in her contributor strategy. One was sort of an office hours concept with every other meeting, I think it was. Well, now it's just every meeting. Yeah, so yeah, because we were gonna try to be like super coy and be like, oh, every other meeting and like, oh, this meeting will do these things and then we were like, whatever, everybody come. If you need help, we'll figure it out. So yeah, I would love for these meeting every Thursday, at least not necessarily this one, but all the Thursday meetings for contributor strategy, we should make the projects feel comfortable to come to us. Or if they need for us to come to them, we should also have that as a service because I would also think it's cool if we could go to some of our community meetings so that it looks like we're bridging a gap and not necessarily people have to come to the principal's office. So that's what I've been telling some of the other projects too. If you want us to come to you, we'll come. We can schedule another meeting, we can be in the open and whatever you want us to do, we'll do it. I do actually kind of wonder if it would be useful, particularly after you've gotten, particularly after we have some kind of a way to reach maintainers, to actually do something with a topic, like to say, hey, we're gonna have a meeting where we talk about, how do you recruit maintainers from outside your company? Or how do you figure out who's gonna enforce the COC? The- Got a recruiting playbook set as an issue for under our repo that I hope to eventually start on. Josh, I like your idea of having an upcoming thing of here's the next few topics, because often we have so many things on our plate in community stuff that having a deliverable of a date for a smaller subset of things that would result in direct benefit to the community on a rhythmic basis, I think would almost allow a continuous release valve of good without us constantly being under a wave. And it doesn't take all of us to do that thing. We can alternate out on who's the release valve for innovation or community support by having some type of a topic list and people picking up things important to them and inviting people to come here about that. I don't know, it's something not quite congealed there in my head. Yeah, I mean, I was honestly also kind of picturing the maintainer circle, contributing to this as being kind of at self-help with us assisting. Hippie, you should help me with that. I think you should. I, yes, ma'am. I'm like, I am yours to assist on all of these things. If I can get one more active person with me, we can hoist this up. Right now I've got 0.5 of myself and that's it. So if I can get 0.5 of you, we can have one and we can hoist this maintainer circle up. Yes. The problem is, and I'm not blowing the scope of this meeting, but the problem really lies with a lot of the value here was in person with in-person events and stuff like that. But obviously we're gonna make it work and things like that. So that to me was kind of like, what took me from a one to a 0.5. It was like, so it's just kind of like, you know, my personal dreams. But anyway, we can still make something work and make it wonderful. I don't wanna make it another Zoom call though. That's what I'm nervous of. Like I wanted to make it so people feel camaraderie and like, and you know, something meaningful, not necessarily. I wanna make sure I hear you. And the contributor circle is something that we haven't been able to give our efforts to fully. And part of that is due to kind of the punch in the gut of not being able to have that. And I'm stepping with you into that and owning it as well. So for us, from our sake, we really like the first thing we need to put together is like Zoom calls. And that to me is like just, that's the gut kick where it's like, oh, I'm curating a yet another Zoom call. But maybe it'll be different. So I'll take you off, I'll take offline and we'll talk about it. And I'll show you all the documents and that we have so far. I would love it. Thank you, Josh, for sharing the call with Paris and that topic with that. I, you know, it's all pretty closely interrelated. Like, you know, you don't get, and, because one of the other things is that, you know, I want feedback from the maintainers on like I'm waiting for the survey to see what people say are their main problems. Before I say, hey, we're gonna have an open office hours on this topic. The, so the, okay. Yeah, because right now the mentoring we're doing is one-on-one mentoring, which as we all know, doesn't scale. Although it's helpful when we're talking about mentoring projects, which means that the numbers we're dealing with are much smaller. But it is a little silly that I am currently working with two projects I know of on the exact same problems. And I'm like, you two should be on a call together. Because you have exactly the same problem for the same reason. Josh, you've caught that for the two projects that you're involved with. And I wonder if from the CNCF perspective, we can ask that question of what problems are you seeing in the last two to four weeks? Because, and then it won't be, I think waiting for a yearly report's hard. But I think if someone's constantly, you know, kind of having that heart to heart with the, with those community leaders and finding those pain points so that the topics and maintainer circle can kind of address some of those. Because to be honest, the news during a particular week can totally influence the, the where people's minds are for that week. And it can't wait for stuff to show up in numbers. It's gotta be eye to eye. Yup. So I'm glad that you're taking that time to do that. I guess what I'm trying to understand is how we can have those conversations about what it looks like at a CNCF level to ensure that that is not all on one person and that it's not something that's not put as a high enough importance. Yeah. And I don't know. At this point, CNCF is having staffing issues for the same reason that many other places are. Yeah. So if I feel like crying right now, I'm just gonna let you know it. Oh. Oh. This is hard. I don't know. I feel like honestly, I'm still enjoying this because I kind of feel like, look at the big picture here, right? Which is that we get to create order out of chaos and help people in the process. Yeah. It's just that there's a lot of chaos, right? That we're right now facing this giant vat of chaos. And it's going to take a while to get that to rights. But I've also noticed, time in Kubernetes, I've noticed how quickly something that you introduce as a practice to solve a problem becomes institutional. Like, you know, I haven't had to intervene in anything with the release team for six months. The, and now we're trying to export that to the CNCF in general to make it a system. Quick question for you, Paris, before you jump. Oh, no, never mind. The question's already answered on the issue. So never mind. Okay, bye. I also need to go. Yeah. It was wonderful to speak with you both. I will speak with you all soon. Okay, thanks so much for coming. Yep. Bye. Thank you for being here.