 Well, it seems to be working, Josh. Oh, OK. Yeah. There was just no noise. There was just no noise. And the first headset wasn't working. It was definitely not working. Oh, OK. That'll happen. Well, it's the other one is cordless, and the battery died. So the. Almost like Monday. Who knew? Yeah. So, OK. Welcome, everybody, to the SIG Contributor Strategy Governance Working Group meeting. This is a recorded meeting for the Cloud Native Computing Foundation. The, let me post the link to the notes here in the chat so that everybody can put their names down. So if you want to add your name there. The we only currently have a couple of things on the agenda for this meeting. Oh, wait, first thing, this is an official meeting of the Cloud Native Computing Foundation. Therefore, we are under the CNCF Code of Conduct. So please, please behave as you would with your more civilized relatives. And we can have a good discussion about things. And like I said, do put your name down on the notes if you are here attending. Because I see seven people here and only two people, only two names on the thing. This morning, we only have two things on the agenda. One is that the steering committee proposal has been raised again on the TOC mailing list. And wanted to leave a space open in case anyone wanted to have any discussion of that. I do see that we have two contributors here from the NAPS project. So if they're here to speak, I would be interested in hearing their specific opinions on that, whether or not they think a special steering committee arrangement would be helpful for NAPS. But beyond that, we'll go over that. I wouldn't mind taking some time to discuss that because our second item, unless somebody is going to add something to the agenda, our second item is to actually get all of our documents currently in draft, which are all advisory documents merged. They've been sort of hanging out as PRs for an inordinately long time. But half of those drafts were primarily authored by Dawn. And she has told me she's going to be joining us late. So I am happy to wait for that agenda item until she joins. So that said, does anybody, if anybody else has something else to add to the agenda, please put it on that document there. Otherwise, we will go ahead and proceed. So steering committee stuff, because the people who joined, let me do a recap. So I don't know, a month ago, Alexis made a post to the TOC proposing that the TOC adopt a kind of steering committee workaround for the multi-organization maintainer requirement. That is, the CNCF currently has a requirement for projects to reach the graduated level that they must have maintainers for more than one organization. Alexis drafted a proposal, sent it directly to the TOC. And proposed that the TOC recommend to projects that they adopt steering committees that were multi-organizational, in place of having a multi-organizational group of maintainers. We had a meeting less than a week after that, a governance working group. We spent almost the entire meeting discussing this proposal. In the end, we recommended against the proposal on the basis that a project that has reached the point of proposing to be graduated and has not attracted a single maintainer from outside the primary participating organization has issues that cannot be resolved by a steering committee. And while steering committees can be great for projects for other reasons, they are not effective for this particular reason. That was our recommendation, which we sent to the TOC. It's important to know for people in this group who don't attend the TOC meetings that this particular proposal has still not been discussed. I know it hasn't been voted on by the TOC. Also, it's not actually on the agenda because it was proposed by someone who's not a TOC member, so they're not actually required to vote on it. The status is pending, I guess. Hence it coming up in the TOC again. And since this is the governance working group, we wanted to provide an opportunity to discuss this particularly with new people who did not attend the previous meeting. So with all of that brought up to date, our open questions are, one of the other things we got out of this in the governance working group, which you recap is, our output for the governance working group is to prepare a body of advisory documents for projects to develop good governance and to assist the TOC in improving, maturing, evolving the governance requirements. So one of the other things that came out of it was that we would prepare a document that included advice on establishing a steering committee if you want one, which is currently in draft. It's one of the things in the second half of this agenda to try to get merged. So with all of that, we have some new people here. The question is, do we want to revisit? Do we want to do anything additional around steering committees beyond what we already have drafted? Are there other things that the governance working group needs to do because of this ongoing discussion? So feedback. And for that matter, we have two people here from Nats, and I would be very interested in hearing from them since they have not spoken up in the TOC discussion if they feel that there's a path specifically for Nats. So not necessarily a general path for all C&C projects, but a path specifically for Nats that involves a steering committee as a way of dealing with some of the governance wonkiness that's been discussed. Stepping back a bit, this is all about the health of a project. And in terms of looking at that health, when you have projects that span multiple repositories, we have 90, right? How do you determine whether, based on these repositories, whether a project is healthy? Do you take it as a whole, or do you pick out a few to determine the health? And I'll just share our position. As a whole, we have a question from GRPC. Yeah. Sure. Yeah, I mean, as a whole, on the Nats team, we have a lot of many, many different companies contributing. The repositories for our servers are admittedly very synadia heavy. And that's because it's not a weekend project for somebody. It's a very, very strong investment in time to actually get something running in the server. It's very complex, highly performant. And I've had my own PRs rejected because they didn't come to par. So in that, we've been working with the community in taking their input, and we can deliver their features with much more efficacy, which is better for the community. So in terms of project health, if you have, again, if you have a project that spans many, many repositories and overall, it's very, as a lot of maintainer diversity in terms of companies, where do you stand on that? Well, first, this is a discussion. And second, you touched on a whole bunch of different issues, so I'm not sure exactly what question you're asking. OK, wow. Yeah. Well, the question I'm asking is, in terms of governance, if you have a project with many repositories and diverse company contributions there, but a few core repositories that tend to be company heavy, where does that stand in terms of health, in your opinion, and then in terms of governance around to, based on that, where do you go in terms of governance? What's your recommendation? Yeah, if I can add to that, I think a lot of it is, like we've said before, we're trying to solve this mysterious diversity issue for governing, I mean, for projects that want to graduate. And we don't really know what that means exactly, so it's a bit of a moving target in the sense of, like in the case of NATS and GRPC, you can look at the core for GRPC, and, well, I mean, there is more than Google maintainers, but there's not apparently whatever the number is that the TOC is looking for. But then there's repos to Swift and other stuff that is completely controlled by other contributors. And so I think that's the same thing that Colin's saying, is like, these two projects in particular are very different than I think your standard project that has the one core kind of repo. So it ties all back to that original question we're trying to solve of this diversity issue and the steering was proposed as a way to maybe have, at least my understanding was, to have an overall governing body that could kind of represent the project overall instead of, again, for GRPC, like the Swift repo, obviously the Apple devs, that's theirs. So when it comes to what features go into that implementation, it gets deferred to them. And so I think the idea that Alexis had proposed was kind of like you have a steering committee for these projects that is composed of people from the different repos. And then they become one big group that kind of oversees the health of the project versus looking at a project as you are your one core repo. And that's it. And we assume that any health of the project is dependent upon that one core repo. I hope I did you right by that call. But I think that's at least the thing that I know we've dealt with this with GRPC is we keep coming back to that same question of it's this mysterious thing of what kind of diversity are we looking for when we say the diversity requirement? Because even you, Josh, mentioned having a project that didn't have at least one other maintainer from someone else has its own problems, which I agree with. But the number is it's N plus 1, essentially. And we don't know what N is. So yeah, I think that's what the steering idea came from, was that it was a way to address some of those diversity concerns without having to say, for example, you have to have 10 different maintainers on the core infrastructure of a project when you may not actually have that many other people that want to do it. So I think that's how I've interpreted things up until now with regards to what the steering committee idea. So I think that does tie into, like you were saying, Josh, not every project needs this. Because this is kind of a unique situation that these, like NASA and GRPC, we're more of an implementation than a standalone project. And so I think that's a lot of what the thought behind it was now. I know from the GRPC perspective, I'm totally cool with the idea of a steering committee. And so has everybody else been. But it doesn't sound like that's going to be enough to solve the TOC diversity issue. So again, it's just kind of like, all right, what? I feel like we still haven't had that defined. Yeah, well, so but I mean, this is a case of, in this case, what you're discussing is let's take the problem with the TOC's way of evaluating projects and move it to a steering committee, which still doesn't solve the problem from my perspective, right? I mean, the TOC should make the decision of either that there's some sort of qualitative test for whether drivers and plug-ins and supporting repos qualify for maintain or multi-org or don't. Right? Yeah, and I agree with you. That means it needs to be solved, right? And if that's not solved, it doesn't matter if these people are sitting on a steering committee or not. I agree with you completely. That was my understanding of what, kind of like when Alexis was proposing the steering idea, that's how I understood it. It was like, hey, here's a relatively easy way to say, we've got a lot of representation from other orgs. But you don't have to necessarily, each project has its own requirements for how you become a maintainer. But yeah, that was how I understood it. And like I said, it might work fine for GRPC and NAS, but to your point, it doesn't solve the issue for any other project, although I don't know of any other project that's had this issue. Are we aware of any other CNCF projects that have had similar issues trying to graduate? What about TIKV? Yeah, and that was a good question, right? Is TIKV graduated? Is it? I don't know it. Did they graduate? They've been proposed for graduation. And I believe that they have, they've got like, I don't know, eight or nine maintainers, two of whom don't work for the main company. So that's why I keep saying these low numbers is that the actual written requirement for the TOC is not substantial. It's not a majority of maintainers. It's not a specific, the specific number is one. I would say, is there, I didn't even know that there was that. No, there have to be maintainers from multiple organizations. So OK, but then why did, OK, because we have, I would say, April, we've had this discussion with them since we started our graduation trek is that the requirement says two or more. Well, even on the number of or we have two or more, but apparently that is not, it's subjective. So two or more. That's what I was going to say. Yeah, it's a very subjective, it's a moving target. So it's very difficult for us to figure out what the TOC actually requires from us. Right, right. So one of the things that I think subjected NASA special scrutiny is that you have an unusual arrangement with what is it, it's maintainers and core maintainers. We have scrapped that. Oh, really? Yeah, OK. Because that would. Even then, that's not really different than owners versus, like, other, it seems like other projects have owners, maintainers, and then approvers, and I don't know. I cannot tell if TIKV has graduated or not, and I don't know why Amy has not responded yet with her encyclopedic knowledge. Maybe she can't tell either. Everything. I just wanted to raise my hand. Amy knows everything. The. I just wanted to start, like, OK. Not just as a Nats maintainer, it's my first time at this course. Welcome. Yeah, thank you. So yeah, it's very interesting to follow the discussion. So yeah, my name is Wally. I've been involved in the Nats project actually for around seven years now, even before Sinadia and before this other upset I could use to maintain as well. But so yeah, it has been out there for a while. And so what I really do, the steering committee proposal when it came up is that it puts back some of the into the spotlight, some of the end users and what they need instead of, like, the livelihood of the maintainers. So I mean, as a Nats, as a Nats maintainer, you do want, like, the best for your project. But we also want to graduate to bring away, like, without, like, it costing us everything, you know? And right now it depends. You need to, like, basically maneuver where it depends on the livelihood of the maintainers. Like, they have to be, like, either not working together, working together. So the steering committee, what I feel is like switches back, put things into the spotlight of what the users need and to satisfy the control requirements about, like, not only one company being in control of the whole project. So that's, I just wanted to share my take on it and, like, what I feel that the steering committee proposal could be of value for us. So one of the things to me is that both the criteria that are set through things like graduation requirements and also a proposal at establishing steering committee as a mechanism is that there's often a pretty big gap between theory and practice. And what really matters is how a team of individuals and however they're arranged in terms of their sponsorship or how they're engaging with users and accepting third-party contributions, it all has to do with how the overall project is collectively practicing. Like, what is actually going on? And that the steering committee kind of proposal as a document, it's like, well, maybe you could implement a structure that's kind of like this, but it doesn't necessarily translate into how that will turn into the overall conditions that we want to cultivate, I think. For me, it kind of gets lost in translation. Exactly what are we trying to achieve? Where are the outcomes? We want people to feel comfortable that if you have a meaningful contribution that completely makes sense to get into an open source project, that it's going to be weighed on its merits and not on some agenda that is external to the collective. But I'm not sure that the steering committee as an organization of you could implement this kind of group of people if that's really going to get where I think we want to be. Yeah, I think it goes back to, again, what is the ultimate goal? And I think that's kind of the open question of when we say, like you said, one big plus one, and then also just kind of that understanding of what exactly we're trying to make happen. And I think it then becomes another question of like, there's always been this understanding that CNCF didn't mandate project governance. But if you are going to say that in order for a project to graduate, it has to have XYZ in its governance, then is that effectively like a rule? But you know what I mean, you get to the point where you're no longer saying benevolent and dictator for life projects are totally welcome to graduate. And that may be 100% what the direction the TOC wants to take. But again, we just need to know if it is going to be the kind of thing where I think, and I said this on the email, I think we can all agree, every project is different and needs something different. But if we can have the TOC kind of tell us what exactly it is they're wanting to do and if they are wanting to say, here's three governance models that we really like, projects pick one of these, then that's something that we, as the working group, can then create templates or guidelines or whatever. We just need that direction. And I feel like that's the thing that we've been kind of struggling to get. One of the things that I personally believe in, and I'm just speaking for myself here, I think that projects work best when the people who are doing the work are empowered to find the mechanisms and the overall conditions and mutual trust in one another that they think that makes them most effective as a community. And sometimes that may mean that in some point in time in a project's overall development and history, that might mean that individuals are going to be most effective if they're able to have a closer connection to one another through shared sponsorship and being on the same team that's like building something together. But what we want to cultivate is an intendedness in that team of people that they are collaborating in ways that are going to help that project grow and have a very long and fruitful existence. And one of the things that I worry about in lots of different frameworks that we use and kind of evaluating performance and graduating the different levels, I think about this in the same way of what does it take to get promoted at a big company? Well, you have to go through and check all these boxes. And if you get too specific about exactly what the boxes are that you need to check to be promoted to the next level of engineer, you end up with an anchor bias. You end up losing the personal narrative that's a very individual kind of aspect of someone's career and progression, right? You just lose all those details if you get very specific about the criteria and it has to look like this in order to move up to the next level. Yeah, that's a really great analogy. I like that. Yeah, so I do want to clarify something, which is one thing that we did ask the TOC and they did decide is what the aims of the maintainer multi-organizational requirement were, right? Because there's a variety of reasons why that requirement could exist. And so we asked the current TOC to make a determination on what their reasons were. And the reasons that they picked were number one, openness, that is, that CNCF projects are required to be open to contributions from all over the CNCF ecosystem. And having a person who can merge code or having people who can merge code who work for more than one organization is a tangible demonstration of that. And the secondary reason being continuity, that is, the CNCF includes startups, some companies have over the CNCF lifespan stopped being involved with the CNCF. And as a result, if a project gets to graduated, the CNCF has a soft commitment to make sure that project continues in some way. And if 100% of the people who regularly work on code for that project all work for the same organization that adds a significant risk to the continuity. So those are the two reasons that the TOC picks in terms of the two aims. And obviously, given those two aims, and the reason why I wanted to get aims is given those two aims, you can imagine other ways to satisfy. Is that what Tufted? No, I wasn't part of the evaluation, so. Okay. So to the first one I would say, I don't know what the NATS maintainer process looks like, but I know for GRPC, if you wanna be a maintainer, all you have to do is ask. So the fact that we don't have a lot of other maintainers isn't, the barrier there is something that I think, I know Paris has talked about a lot with the overall strategy seg of like how should CNCF be kind of, I think this all kind of ties in, like how should CNCF be helping projects get new maintainers and grow that kind of incubation status of like, to your point, if a project has been donated to CNCF and then everybody just like wins the lotto and goes to retire on an island without computers because that's mine. I don't like the bus factor or like the island with no electricity factor. Then like CNCF is ultimately left with the project and so has to find a way to keep it going. So it's kind of like, what kind of, I think that's a lot of what, the contributor strategy you're trying to figure out is like, how can we better serve projects to get those maintainers? And I think that some of the, again, not gonna speak for the NATS folks, but I know at least from the GRPC side, a lot of it is like, we don't have the resources necessarily to go out and actively recruit a bunch of extra maintainers. And I know a lot of smaller projects are even less resource. They don't have a me or a Paris or whoever. So how can we make a program that scales up basically for all of these projects? Because especially like, I don't know how many projects are in CNCF right now, but can you imagine when they all went around the way? It's like 70, something like that? Crazy. And so like, when you imagine all of them have graduated, you know, like the logistical overhead starts to become a little, a little much. And so it's how can we create these tools that projects can use and then it can scale up. And so that the CNCF ecosystem is assured, it'll keep going even if we all win the lot. And I think this new maintainers from other orgs sort of turns into a chicken and egg problem, right? Because until you get those first couple from another organization, it looks like maybe I'm not welcome because all of the maintainers are from another company and it's really hard to get that first one or two from another organization because you don't have any. And so you get this, you do get into kind of this loop where it is really hard to get those first couple. But I think once you get over that hurdle, like it's a little bit easier, but we need to probably, I don't know, provide some guidance or help, I guess, for projects in that state. And some of that is incorporating, I think in kind of my past experience, is incorporating something that's very mindful in your practice is like a maintainer or project leader of trying to find people that are demonstrating kind of that interest and inviting them in, right? And sometimes that can be hard if you have a small team that's like, that's not necessarily keeping a mindful kind of outward focus and looking to draw people in and encourage them and invite them to do more. And looking for the sides, they're like, okay, we should look for ways to give you more opportunities and then more responsibility and authority over time. It's very much a part of growing people. And all of that is like, to me, it's much more about the people aspects than the company affiliation parts. And I think that's where sometimes we get a little bit myopic about like number of companies that can be represented and all this kind of stuff. It's like, you can, yeah. I think by the time we get to sort of graduation, I would like, it would be nice if projects have gotten over that hurdle of just like the first couple because I do think that that shows, I mean, you're right, it is kind of a person problem. It's kind of a resource problem. It's people problems. But I think it shows a project's maturity that once they're starting to get over that hurdle of having the first couple of maintainers from another organization. And I think it's important now, I mean, numbers aside, I don't know how that's the hurdle we need to figure out, but I do think it's kind of important to see that in a project. Well, I think it also, again, like GRPC, we have a lot of, I don't even know the full number. We have a lot of different repos because we have a lot of different implementations. If there are 20 Apple devs working on the Swift repo and I know Salesforce has done a lot with their reactive, I think it's reactive JS, that's all well and good, but like they can't take over the entire project should we all win a lot of, you know what I mean? Like I think that's the issue that comes down to is like, this standard that we have works great for some projects but it doesn't work for every project. And when you do have something like GRPC and NATS that have this much broader scope, you can't apply the same standard because I could have one repo, like the go implementation can have 20 different companies, 20 different people from 20 different companies represented on that maintainer list, but that doesn't mean they're gonna pick up should the rest of the repos and implementations just fall away. And so I think that's where we get into this situation at least from the NATS GRPC side of where it's like, it doesn't work for us. And it's not, and what made me think of this is specifically like what Matt was saying about, identifying those folks in the community and bringing them in and with the GRPC case, I have done that. But again, it's Ryan who's written his own implementation and that's great. He is happy to control that repo but he could not take on all of it should something happen. And he quite frankly doesn't necessarily have an interest or even the skill to take over the core implementation which is like C++. So then it comes down to the issue of like, you can't expect the Java maintainers to be responsible for the go implementation, et cetera. And that's why we get in that spinning cycle. And I'm sure it's very similar for NATS. It is, it is and I do think this needs to be quantified. You know, I agree that that does take some of the personal aspects out, right? The people, the connections, but we've met the letter of graduation for over a year now, you know, a letter of the law and quite frankly, the bar keeps moving. So we're looking for something to help us move forward. And, you know, if that's a steering committee, great, we're all on board, but we just, we need guidance. What do we need to do to graduate? Yeah, and I think it ties into like, you know, and maybe this is something that we, as the governance working group can kind of take a stab at of like, if we accept the, you know, I'm thinking of it like a science project, like if we accept a proposal that not all projects like Kubernetes, then what are the different types of projects? And, you know, I know we've talked about different things about like having labels on GitHub to show like the status of a project and, you know, be more specific as to call out whether or not, like it's one maintainer or multiple maintainers. But what if we kind of take this approach of like, hey, we see there's X number of projects that have this type, this structure that requires a little extra handling. It's a little unusual. And then, you know, we can advise the TOC on, you know, hey, recognizing that there are these different types of projects, here's how you should really apply the standard to these different types. Does that resonate with anybody? Yeah, I'm right. I'm dubious that you could quantify the different types, but. Well, and yeah, it's probably again, like N plus one, you know, maybe it's almost like an audit of the existing CNCF projects, which there are 66, exactly, Amy tells us because Amy knows everything, and she's awesome. But if there's 66 different projects, like can we do some sort of high level grouping in terms of not necessarily the governance model they have today, but in terms of like, is it a mono repo? Is it an implementation? Is it something that is meant to be a platform and therefore could have, oh, 63, she says. So there's three more, she owes us. You know, so like, is there something that it can be, you know, a platform that people could build on top of where theoretically if the main piece was no longer maintained, you still have these other pieces being made, things like that. Like, I wonder what you can just do kind of a high level audit of all the different projects. And I wonder if that would also tie into some of the work from Sting Trip Strap, of like, you know, Paris has got that, we did the survey of like what, you know, models people have and things like that, but we can potentially kind of tie into some of the work that they're doing and do kind of this overall look at like the different projects and kind of where they, what grouping they fit in. You want to take a stab at that? See if you can come up with some reasonable groups. Oh, April, did you lose sound? I think I'm lost, I believe. You are kind of digitizing, okay. So I think to me, in an approach of like grouping existing graduated projects and kind of inspecting their governance and things like that, it's like we're trying to do a sorting hat function, you know, who's going to be Gryffindor and who's Slytherin. And it's also, it's a point in time. And I think that the really resilient projects in their communities evolve over time. They grow, they change, they, they were like, well, we tried it this way last year and then that wasn't perfect. Like there isn't, there aren't any, there's no perfection in any grouping of human beings, right? And the only thing that you can do is try to continuously improve. And if you look at a point in time, you're like, well, here's a governance structure that we have today. And then, you know, like what said earlier, you know, we have this different levels of maintainers asked and we got rid of that. Hopefully that we got rid of it is because we found that it wasn't functioning the way that we wanted. Like it caused some kind of outcomes that were not overall beneficial to the way the project runs and not we're trying to meet the criteria for graduation, right? If the goal is we need to graduate to get to, you know, the next level in CNCF, but that overall is not aligning you to build the best, most vibrant, most diverse, most resilient kind of community, then that's not necessarily, the overall mechanics of the incubation sandbox graduation type process is not leading to the desired outcome. And we need to look at that, I think. Very true, and as far as I'm aware, post-graduation, there are no requirements for a company to keep the standards that were given or they met in graduation. And that leads to kind of looking at, well, we need to make sure that there's governance there that is going to maintain that status at the time that we looked at, having met the graduation criteria, right? And so that in practice, I think, I might be wrong about this, is just my intuition. I haven't really done a deep inspection of these kinds of product, but that often means that it becomes really hard to change the governance of a project, which means it actually makes a less resilient community because you're not able to adjust for changing dynamics. Okay, I'm gonna pause you there because we have 13 minutes left and I would like to get our outstanding pull requests resolved, preferably, on this call, because this includes advice to projects on leadership, which is obviously relevant to here. So let me do that and then we can go back to this if we finish in time. Okay, let's see if I can actually, oh, somebody sharing? No, you just blanked out. Okay, there we go. So we have four outstanding pull requests, although the project health document is actually waiting on contributor growth working group. I believe it's already been approved by, by this working group. So there's a couple of things here. One is just a few updates for governance references. For those of you who are not aware, we have a document here that just has a large list of references for things to look at. Is there any reason to not just go ahead and merge this? I've already checked it to make sure the links work. Yeah, this actually, I think wasn't, wasn't about the links of references. This was about the governance working group was still listed as proposed on the read me. And so I fixed that. And instead of linking to the issue where you were talking about it, I linked to our governance working group read me. So it was just a cleanup. And I added the meeting time for this meeting, which wasn't on there. Okay, so quick check for any objections. Otherwise we'll go ahead and merge it. And then a longer one, primarily authored by Dawn, which is advice on leadership selection. For those of you who actually haven't looked at this, this is a long document saying, hey, here's a whole bunch of different, a whole bunch of different ways that you can compose the leadership of your project, including a steering committee. And again, this is advice to projects on how do I build an open project, et cetera. It's been out there for a while. This PR was actually the result of a previous drafting process that we started at one of these meetings on a Google document. Obviously this document is not 100% complete because no such document ever could be 100% complete, but I think we should merge what we have so that we actually have something. So any comments or objections? And this is pull request number 52 if you wanna actually look at the full text yourself while you're on this call. I don't object to that. I confess I haven't had a chance to actually read it all yet, but I think it makes total sense to just get it out there and then we can edit as need be. Yeah. I mean, I feel like we need to have a higher standard for, well, the thing is, you know, with all of these, even after we approve these, there's still one more stage, which is that the TOC needs to approve them and then put them in another location, which they still have not determined where they become official advice to projects. So the, okay. So let's go ahead and merge that. And then the last one here is a second draft of what is governance? So the history of this one is, this was a bunch of material written by me and Brian Barenhousen of Red Hat for the open source waybook that I revamped to make it specific to the CNCF projects and then got a lot of input on it from the rest of the governance working group and then opened it as a, oh, this still needs a couple of changes before we can merge it. Then open it as a PR. It does need a couple of, there's still a couple of outstanding changes, some things that MSW pointed out so we can't merge it at this meeting. The, so all I'll say is please leave your comments on it in the next day or so. Otherwise, you know, and beyond that, we'll resolve what's outstanding and merge that. One of the weird things about this one, like a couple of others, is that it has some bed end links in it because we have a whole, and so then this brings up the other thing is we have a whole plan set of documents which we have barely started on. And this is a call to everybody on the call if you want to take on any of these plan documents. Please go ahead and do just claim them in that issue if you want to avoid duplicating somebody else's work. You're not even required to claim them, but you know, it's always annoying to duplicate work and say, hey, I'm going to work on this because we want to get all of this material out to projects so that we can say, hey, here's a whole bunch of advice on how to improve governance for your project based on people who, you know, have experience doing it for other projects. And as you can see, we have quite the list. Okay, so that is pull requests. I don't think we have any open issues other than that. Oh, the end user promotion criteria we need to actually take back to the TOC. That's another one where clarity required. And obviously we've spent a long time discussing the multi-org thing which is why it is not resolved because we keep discussing it. So, okay, so back to discussion because we have five minutes left unless somebody else has something to say about current open pull request and issues. Okay, so as a result, we got a couple of things merged. Any further discussion on this? And since we only have five minutes left, let me encourage people. We have on CNCF Slack we have the SIG Contributor Discussion Slack. Please comment on that. You have now seen, if you weren't previously aware of some of the issues in pull requests we have in the SIG Contributor Strategy repo where we discuss these matters. Please use any or all of those mechanisms to continue following up on this. We don't want to lose anybody's input. And there are obviously specific outstanding problems that we want to resolve whether or not we resolve them with the steering committee. Okay, well, I think we're all on the same page in that we all want healthy projects and we want what's best for CNCF. And I think this, hopefully this is a productive discussion and we'll keep churning through this. Cool. Okay. Well, thanks everybody and thanks for participating in what was a great discussion. And I'll see you and all the other things and plus we'll have this meeting again in two weeks. Sounds good. Thanks. Thanks all. Thanks everybody. Bye. Bye.