 Hello, I can't, howdy, hey, now I can hear you. Yep. Thanks again for moving this to a UK friendly time for me. I appreciate it. Oh, it's not a problem. I mean, we put in the afternoon just to begin with because we didn't have any Europeans joining us and knew that we might have to move it. You know, but for all of us who are here in the US, speaking in the west coast of the US, we have this thing where our mornings are packed full of stuff and our afternoons are pretty much free. So, I have the opposite thing like anytime I can schedule something in my morning because my mornings are wide open and then there's this chunk of US overlap that's just booked solid every single day. Yeah, the, yeah. I'd rather have that honestly because I think I would get more non meeting work done. My problem is always, you know, after having five hours of meetings, I'm pretty much wiped out. Yeah, it actually works really well for me because I tend to work better on focused work in the morning anyways. And so it's really nice to have this chunk of time where I can just get stuff done. And then and then have all my meetings. So then you guys just get me when I'm sleepy and tired of working all day, but I'm smack in the middle between the two of you. Yeah, that's true. You don't really get a nice chunk you get like all your meetings are. Yeah, sort of in the middle. You probably don't get a lunchtime. Okay, so we have a relatively short agenda, although there's likely to be some discussion. One is, we have sort of an outline for we've got the content development issue. We have the ongoing saga of the maintainer multi organizational requirement. And then if people have other business, other things that they're working on that they want to bring up. So let's go ahead and get started. So this is an official meeting of a CNCF working group as such a subject to the CNCF code of conduct, which all of you are familiar with. It is also being recorded and shows up on some CNCF YouTube channel somewhere. So do keep that in mind. And we will get started. So welcome everybody. So our first thing is I we sort of hammered out a little bit of an outline so a big portion of the work of this working group is simply preparing a whole bunch of written content as guidance for the projects. The, and this basically falls into two types of content. One is general content about developing governance for open source projects. And the second part is specific guidance on the CNCF requirements at the various levels. The latter being, you know, we need to write a document on. Hey, I, you know, to become even a sandbox project you have to adopt the CNCF intellectual property policy what does that practically mean for your project. Right, what do you actually have to do other than saying you adopted it. So I've got a relatively large checklist of items here. The, the other thing is a lot of these items are going to overlap heavily with contributor growth, because things like a contributor ladder is both a contributor growth document and a governance document right because obviously we have certain governance rights, but contributor growth is how we decide who becomes a maintainer, etc. The so we'll be collaborating on those. My main reason to put this up was actually honestly for people to volunteer to take individual things. As you go. So, got that issue there, which is linked off of the table contents. So, any comments, thoughts, volunteering, or any of these I'm still getting up speed or any of these work in progress already do we have bits and pieces of these and other documentation. I have a bunch of bits and pieces my next thing to do is to actually start pasting them into the repository as PRs. Because there was some hold up on starting the working group. I've been in parallel for general governance advice I've been in parallel working on red hats new addition to the open source way governance chapter and so I need to paste a lot of that in and modify it to be suitable for the CNCF stuff. So that's the main work in progress I have for a lot of these other things honestly we can pull examples from the projects who've already done them well. Like for example the role documents there's a couple of projects that actually have good. This is who's a member of the project this is who's a contributor this is who's a maintainer sections already written up. And a lot of our documentation can be just pointing to those as examples. So yeah, so people have stuff it is not in our repo is the current status. Okay, so we can just kind of search around and look at some of the projects and pull together something that looks reasonable. Yeah, and stuff from outside the CNCF to I have a question for the how to create how to write once we're going to have templates that came from your growth. Yeah, are we just going to walk them through like here are the things you should be thinking about. Yeah, is that what is that what it's going to be. Yeah, that's my thought right because they have to, I'm taking from the perspective of hey, they have to have this how to contribute document in order to be accepted. Yeah, into incubating I think. And I mean ideally they have it for sandbox but I think it's a requirement at the incubating level. Yeah, it does okay so maybe they have to have it for sandbox. And, oh yeah yeah sorry it isn't my list for sandbox. And so here it is. And so, I mean that's one of the ones where, you know, and this is why I was asking you for contributor growth, whether we should actually be working on a shared folder for this because it's going to be the same document. And so what we would be supplying from a governance perspective is a little wrapping around saying hey, this is a requirement at the sandbox level and this is, you know, Yeah, yeah so so what we're going to have is the template, which says, like, you can copy paste it use it, and there's going to be in line markdown comments essentially that'll help you with optional parts, or like things to think about. Like, we'd also have in the governance part, or governance will help create a walkthrough essentially. I don't know what the template looks like is a walkthrough actually required. The templates going to have like I said markdown comments if you open up and edit it in GitHub or markdown editor you're going to see those low grade out HTML comments that say like, let's do that what should you think about if your project has this use this section of your project has a DCO for example use that. But it may be nice to have another introductory document that just says why it's important what we're doing what's the goal, because like the template just talks about the brass tacks of like, this is how you fill it out. Because sometimes people don't always understand how it's going to be used and why we care about it as a requirement. If that makes sense. So I think there's still value in having to introductory. Like, This is why you should care setting. Yeah. Okay, some rain is down. What I'm struggling with right now is I don't know where to put the template, or where we would put this document, as soon as we start writing it, you know, like right now it's living in like Google Docs, but I prefer to be submitting PRs at this point. Yeah, I've kind of taken the perspective that if we're in brainstorming mode that we do it in something like a Google Doc or hack MD, because it, it's very hard to do line item contributions via PR. And then, you know, when you've got a first draft and this is how I intend to do the sections that I'm doing, when I have a first draft then submit that as a PR. Yeah, but where does it go. Once we have the PR. Like we talked about having a template repo that someone could actually just fork and use as a brand new repo that follows all this CNCF guidelines and suggestions. But I can't make that so if we could get someone to make that that'd be awesome. And then all of our contribution guidelines, things like that. I got pushed back when I talked about putting it in the other existing repo people. And it sounded like maybe it wasn't the right spot for this stuff so maybe it should be going in our repo. What what other repo. The CNCF. Is it called pressure you. Yeah. I was talking about in Slack the other week that I was kind of confused because either I misunderstood where were we got we were going to be putting some things like the division of the repo is of SIG work versus things we're putting out for people to consume, like our guidance. So I just don't know where to submit stuff. If you just clarify that. Yeah, I don't contribute. Yeah, and I don't, I don't have an answer for that. I kind of assumed that I was going to put stuff in the, in the repo until officially approved by the TOC. Okay. Or adopted at a SIG meeting and then we would move it to some more official location. But that's fine. Yeah, that that's just, that's just me. I think this needs to be an agenda item for the general SIG meeting. Because I don't necessarily know all these repos. Yeah, that's, that's fine. I'm just at the draft stage for some of my work that goes with that contribution bullet point so I'm just like rearing to put it somewhere and get it out of the Google doc. That's all. Yeah. Cool. So I would like to put my name under how to contribute, I guess. Cool. Okay. Do you want to write the preface? Yeah, the basically just like level setting like what are your goals when you're writing this. Okay, yeah. Okay. So I'm going to sign up for the how to write role definitions with some examples, share a bit of experience doing that. Is there much overlap with any of the other, other working groups or other parts of, of the SIG that I should be aware of for that one. I feel like that might intersect a lot with contributor ladder. Yep. And the contributor growth working group. Yeah, and the contributor growth working group, but I feel like let's just all do the work later. Yeah. If so, does it make sense to have the same people. So you said you'd help out with the contributor ladder. Does it make more sense to have you do the role definitions I could do like a how to do the leadership selection instead. If that's, I think that makes a lot of sense because contributor growth isn't working on that one at all. Yeah. Okay, so I can take the how to do leadership selection. It's a starting point. And because I've been hit deep in this I'm going to be starting out with. Well, actually I want to start out with the more general stuff which is working on the requirement side of things to say what is required for governance documentation, because that's something I actually need to push through the TOC. Because I actually want the CNCF to have a more refined view of what what amount of governance is required at different levels. Because right now basically there's this requirement at the incubating level that you have a governance md file, but no particular requirements and what's in it. And so I want to refine that with the idea that you would have a certain amount of sort of skeletal governance at incubating and then much more mature complete governance system at graduated and the TOC will obviously need to discuss that once I come up with a draft. So that will be the next part that I'm going to take, take on. Okay. So that's a bunch of things and then we can keep working on filling another stuff. The, and we need to generally settle on the with the SIG on on where this is all targeted to live. Which is, is obviously a question. When, when, when we have it complete when we have the, you know, relatively complete and merged with content from the other working groups. I also have some open questions that I need to take up. I'm not sure with who. I guess probably with the TOC about whether or not we should be responsible for providing advice around developing security issue handling guidelines and developing release process documentation. Or whether there's somebody else in the CNCF who's responsible for that there is there's a release process requirement. And for that matter, in my experience, the release process is an expression of de facto governance, because as part of the release process you often have to pick and choose which things actually go into a release. The, and often if that's not documented it results in decisions made by one group being reversed by another. So, okay. Does anybody have anything more to say about that. I had a quick question. This is Jennifer. When I look at the content tracking. I'm not sure I'm new to contributing to this group. One of the things I'm wondering is there something that's going to cover like projects maintenance in terms of like abandonment of a project or killing like not killing a project like graceful shutdown like Is that even on the radar. Is that something that would be covered somewhere here. That would be yeah it actually wasn't something I had on the list. And that would obviously be complicated for a CNCF project. That would be another thing that would need to go to the TOC after we came up with a suggested document. So if you want to add things on that because you want to write them or you already have material for them. Then, then please do put that in a comment and I will add it to the general list. And Paris actually has another one which is communications although I thought communications was elsewhere in our sick Paris. Not necessarily. Okay. Just like how you actually operate the said transparency that you say you're providing. Like best practices for recording meetings and that kind of stuff like I call them the governance transparency vehicles. But the Jennifer's question to I think that actually falls in line with the archiving process that the TOC has, but at the same time I don't know if it's extensive yet because we don't they don't have any projects that have gone through that process. So I don't, I think your efforts could be fruitful there that was kind of my TLDR as well. Okay, so I'm adding these to the general advisory list. Okay. Yeah, and if you think of something later please put it in the comments on the issue and then I'll add it to the list. I mean I'm basically seeing us having a large collection of documents about project governance. The other thing actually whoops the other thing I need to add here is a resource list, because we also want to have a list of external resources, because they're going to be lots of things that we want to point to as general good advice for projects that aren't necessarily going to get copied into our repo for whatever reason, possibly because we don't have access to them. So. Okay, anything else. Cool okay. So the next thing is, I want to report back for anybody. We need to get this in the notes. I want to report back for anybody wasn't able to attend the to see meeting early this morning. So to see meeting early this morning, decided to discuss the maintainer multi organizational requirement. There's a requirement within the CNCF that in order to reach the graduated level, you have to have a maintainer from, you have to have maintainers from more than one organization by which they mean more than one employer. And this has become an issue for some projects that have struggled to attract maintainers projects that were generally originated a single company and have struggled to attract maintainers who don't work for that company for a variety of reasons. The. I so a lot of the discussion ended up setting around right before the meeting. Alexis, we're giving Alexis his last name, but dropped the thing of his suggested sort of work around for this for some of the projects which are struggling, which is an advisory on how to create a steering committee. I as a work around for not having a enough of a variety of code maintainers. The, the to see was generally warm to this idea with guide rails. Because the TOC is main concern with requiring multi organization is that a project not be run for the exclusive benefit of a single company. And by having a steering committee who actually had the ability to selectively override the pool of maintainers, particularly in terms of promotion of new maintainers. That would be one way to address that. The, you can take a look at the. And so that was, that was most of the discussion. I actually expected more discussion with people, theoretically challenging the multi organizational requirement, because there have been people within the CNCF ecosystem, particularly a couple of projects that are single organization right now, who are unhappy with the requirement. Nobody on the call challenge the requirement. They were a lot more focused on, you know, what are work around for projects that are having a lot of trouble fulfilling the requirement, even though they fulfill all the other requirements. One of my thoughts in there was, and I've already requested this from Alexis that we incorporate this, his steering committee advisory document in some form into our own documentation. Because it actually is with some cleanup. A good document for hey, here's how you create a steering committee if you need one in order to fulfill CNCF governance requirements. Yeah, I think it makes sense for that to be under our stuff. Dims I thought you had some thoughts. Sorry, yeah. So, what I'm trying to figure out the threat model. So, or whatever you want to call it. It's, it's, who are we trying to protect against, or what are we trying to protect for by adding the diversity. In the maintenance ship. It's, we are trying to make sure that people are welcoming and, you know, we'll mentor incoming folks and add them. So, when also when they take technical decisions and they think about what to do next, they will do it in an inclusive fashion. So basically, yes, we will end up stripping away all those things because, because of this, and it's, it's going to be the default right people will say, Oh, we started in the sandbox as a single company thing. And there is a clause in here saying, Okay, you can just add a steering committee and add two people from somewhere, you know, outside the project to oversee what is happening here and low and behold. You know, we don't have to try. We don't even have to bother about doing anything else that we need to do to build up a community of on the technical side, not on the user side or, you know, from the outside of the. So that's what I'm worried about. Yeah. Yeah, I heard you saying that in the TOC meeting this morning and I was actually I share some of the same concerns. And one of the things I wanted to get to feel from the TOC is like, are they actually okay with this, because it's obviously different from the previous requirement. And what they've said the previous requirement meant. That said, the reality is that we actually have a number of projects already in the CNCF including graduated projects that have what I call figurehead maintainers. The maintainers who are on the list in order to meet the multi organizational requirement who are not actively contributing or reviewing code. And, you know, and without having like, you know, semi annual in depth audits of how stuff actually gets reviewed and approved within projects. That's the only way to prevent that. And so then the question is, would a project with a steering committee that actually had people from multiple organizations be worse than a project with figurehead maintainers. So basically they'll be moving figurehead maintainers into steering. That's it. Right. And that's one of these. Nothing else is going to happen. Right. What am I comments on the document is, is how do we actually tell them that the steering committee is doing anything. Right. Because a steering committee that is not in any way involved with the project is not actually solving the problem, because you're going to point to steering committee and then they can never meet. You know, or they can meet and the meetings have no content. And, at least with figurehead maintainers I can look at people's GitHub history and see who is not actually doing any coding on the project. And for that matter, the CNCF can check whether or not they actually have rights to merge things. Wait, wait, wait. Can I stop you for one second? People who aren't doing any coding on the project. Maintainers, we want to encourage maintainers who don't just do coding, right. Yeah, well, who do show up to meetings, do project management, contribute to design, but they may not be committing code that often. Right. Yeah. Okay, yes. Good. The, but I think I would say even for those people it's critical that they actually have the physical rights to approve things. They do. Yeah, but you may not be able to look at like a GitHub activity graph to be able to prove it. You may have to look at like agendas and see that they came to the meetings. Yeah. And I think, yeah, and I think part of this then ends up, part of this ends up tying in with dealing with other things like Paris's first question of the, you know, how do you keep the communications open, right. Because if you have a situation where you have these non code maintainers were mainly in the project management side so they're not generating a lot of GitHub content that you could monitor via GitHub. And then the project is not taking minutes for its meetings for like it's, it's, it's a bi-weekly development meeting. Then you have no way to tell whether that person is doing anything at all, except by dropping in and interviewing people, which is very time consuming. So, we need to sort of think about that and I think as dims point out by moving the problem we actually make it harder, right. Because now, for the extra steering committee members, if they don't have direct rights to merge things in the code in the docs in the planning stuff, then it's going to be even harder to tell if they're doing anything. They, they it'll be even easier to create figureheads. And then I went from the opposite side. Okay, fine. Let's have steering members. Let's have, say, seven people in total, five maintainers of the representing company, and two from outside like user groups or whatever, right. Then what are the carrots and sticks they have those two people have over the other steering members and the maintainers to actually get anything done. Right. It's literally, there's zero carrots and zero sticks. So, and the one of the answers that came was, oh, we'll have somebody from the TOC to actually oversee what is happening. Like, how is that going to help like it's not like you will take every small request or an incoming PR back up the chain to the CNC of TOC to adjudicate right. So it's, it's like, fine, we'll have a figurehead, we'll have a figurehead just make it plain that it's a figurehead. Let's not try to say that more than be figureheads, right. The, well, my perspective on this and what I would put into what I would recommend putting into our suggestion for the steering committee work around. If the to see wants to embrace this is that the steering committee must have the ability to appoint maintainers. If they can't do this the entire steering committee is a figurehead as far as I'm concerned. That actually eliminates a lot of the, you know, potential for the steering committee to statutorily be a figurehead now we have the problem of the steering committee members not being at all active. You know, that is, they could have the ability to do that but not exercise it. Right, but the steering committee itself could be outnumbered right the number of people not from the company will be lesser than the people from the company. So it's not like they could have the power that they can't exercise it because there are there's only two people out of seven and they won't be able to. Now that was actually one of Alexis's recommendations that for the steering committee work around. No one organization would be could have a majority of seats. Obviously, if a bunch of those seats are not showing up. Then that doesn't help but yeah. So this kind of like reminds me of like the Apache Software Foundation where the the ASF board can kick out everybody who is maintaining a specific project. Yeah. So that does make me feel better from that sense. But then there the Apache she board is not like the steering committee in the sense that they are overseeing everybody. So in our case it would be the CNC of TOC and not the steering committee itself. Yeah. So then it almost feels like why do we even need the steering committee. Just to see if they could be somebody from the CNC of TOC who's overseeing and they can get the TOC to pull the plug when the time is right. So yeah, that that was the other thing that was going through my mind. Yeah, that just having yeah, the. So one of the things Alexis if you look at the long argument. That we had on the issue. One of the things that Alexis was suggesting actually was active to see oversight. My problem with that is that historically the CNC of TOC has not been very active, and has had difficulty keeping up with merely the project approval workload. And so, I mean, CNCF currently has whatever it is 65 accepted projects. The idea that the TOC would somehow actively be watching these projects for problems. Not going to happen. Yeah. Yeah. The, and, and honestly even be able to recognize problems if they saw them. Right. Because like I can tell you, I've been asked to do a review of a couple of projects that the TOC thought were problems. And each of those reviews took me probably an entire day of time. So the other angle that I kind of was talking about in the meeting was like searing is supposed to be non technical, at least on the community side. So on the technical side, who is going to like figure out if the design itself or design changes that are being proposed will actually be, you know, inclusive. And, you know, if it's pluggable, then it's more than one render whatnot, right. So, and if the, if the user committee members on the steering committee feel that it is not inclusive. When will they even know that there is like a design in progress and the design might not be up to, you know, they might not be satisfied with the design. Right. So on the design side, there's going to be still a whole by the time they get to know that there's a feature in progress and there is things might not work the way they would expect and things might be going wrong. It'll be too late, but by the time they raise an alarm. Right. That's the other thing that I was thinking about on the technical side, there is no coverage. There's coverage on the side of like, okay, we are from an organizational point of view, I'm a bank and I'm relying on this software to work and I want to make sure that it works all right and they take our inputs. But then those set of people in the steering will not have visibility into what is happening. Right. So that was the other tack on it. Open design in open track terms. Yeah. The, it's obviously a concern. I mean, for that matter, there's just the concern of the potential dynamic that if you have a, you know, say, a seven member hearing committee, and three members work for the company that employs the majority of maintainers. And those three are all of the technical people on the SC. Then the remaining four are going to tend to believe anything that they say about, hey, what do these API changes mean. I mean, I guess the question is, you know, again, is this a worse situation than for maintainers who don't otherwise qualify for maintainers? Obviously, there's an alternative to all of this, which is the TOC says, hey, until you can attract a real maintainer who does not work for the majority company, you stay in incubating. The end. Yeah, that's a hard call that the TOC doesn't want to make, right? That's the problem. Right. And I'm not going to name any projects, but I would say demonstrably the TOC has already refused to make that call. They have already graduated a number of projects where I can tell you the maintainers for the non-majority employers are not actively involved. So it almost feels like we shouldn't bother with the maintainer diversity at all. It's like, why color over stuff that we want to just do a figurehead over and just take it out, right? I mean, if people don't believe it and they, why pray to a false God, right? Okay, so your general perspective would be that you don't really feel like the steering committee work around actually does anything. Except when it's sincere, you know, because I mean, you can't say on the top end that there is it is completely possible to have a project with a sincere steering committee who's actively involved, that having a steering committee is their way to get input and strategic direction from their end users, which is an idea I really like, you know, and all of those things that you could actually have this. Yeah, it's very easy to game and it's very easy to there's no carrots and no sticks basically. Yeah. That's the problem here. I also tend to believe that projects that have that kind of sincere, sincerely varied steering committee probably already have multiple maintainers working for multiple organizations anyway. If nothing else at least a doc maintainer, you know, even if they don't have a code maintainer, the, because that's one of the other things that I strike here to say, you know, the idea that a project can't even find a doc maintainer from one of their end users strikes me as a little ridiculous. Right. And this is not to take away from the fact that the projects can choose to have steering and they could choose to have steering that is diverse. Right. So if projects want to do that, that's awesome, like, you know, Kate's already does it and other, they can follow the same pattern, but they shouldn't follow that pattern for the diversity sake. Yep. So the other people have thoughts on this. What is the project and get going from incubating the graduating that is so gosh darn important that they that we're bending over backwards to skip. I think key health metrics about the community aspect of the project. Does that make sense. It's marketing, Carolyn. It's marketing. I mean, just getting into Santa sandbox, going from sandbox to incubating. It's all marketing. They, all the companies use this. You know, just getting into CNCF into sandbox, even though we are saying it's not really a full project, people use that for marketing to their employees to their customers. And when they incubate when they reach incubate incubation or graduation, they make a really big deal about it in all their marketing materials and when they talk to customers. It's a really big deal and you know, if they love marketing so much, then why don't they market to their end users and community. I mean, that was a great point. Not even having an end user doc contributor or something like that. Like it's incredibly valuable to your project. Why not take advantage of it. Yeah. I don't get it. I don't understand why we should like. And that is the problem. Right. Why can't we actually dive into these projects where there is a problem currently come up with creative ways to actually do the right things right. Yeah, let's help them. They don't want to be helped. That's the problem here. Yeah. Yeah. And so where that's, yeah, where that's come from is, yeah, something saying an incubating and a big part of the graduated is there's a particular project is actually a couple of projects that are incubating that as code are several years old and actually have commercial adopters and some of those commercial adopters are asking the project leads. Why are you still in incubating. Okay. I mean, another thing I'll say is the multi organization requirement is not necessarily fairly applied across the CNCF. Yeah, the how how diligently it is pursued tends to partly hinge on the project and the majority companies relationship with the various CNCF committees. So the But but the big thing is, you know, is that a lot of these projects feel like hey, you know, code wise the project is mature incubating implies that it's not complete and our users are getting antsy about that. Yeah, okay. And in my case, and one of the things that I've actually brought up to the CEO in a previous meeting is, I, you know, really think we should think about for some of these projects, spinning them off to their own Linux foundation holding area, because for my perspective the CNCF is for common property projects, you know projects that don't belong to a single company, and that if you wanted to belong to a single company you didn't need the CNCF. I, and, you know, and, and, you know, but once they've been, once the IP has been assigned to the CNCF, we can't give it back, legally speaking. The IP is assigned, IP and the code is assigned to Linux foundation, not CNCF. See, Linux foundation, right. Yeah, but the Linux foundation can't give it back. Yeah, exactly right. It needs to live somewhere within the nonprofit arena at that point. But the Linux foundation does have other spin offs that are essentially company controlled. And that could be another one. But the TOC, both this TOC and the previous TOC have been super reluctant to even consider that for any projects. So, I actually kind of want to get a feeling from everybody in the meeting here about whether or not we're okay and obviously I will finesse a write up on this but whether or not we're okay saying hey, on steering committees is super well on steering committees is super welcome because the thing that projects do, but we do not see a steering committee as a legitimate work around for the multi organizational requirement. Is that a statement that that everybody currently in the meeting is is comfortable with Don. Yeah, I would agree with that. Absolutely. Wait, okay, we've got one more person in the meeting is that. Oh, Jennifer. I would agree with it. Okay. Okay. So I will write something and then post it to our slack and tag all of you folks so you can actually look at it before we pass it on to the TOC. Sounds good. Thanks, Josh. Yep. Thank you. Thank you for bringing that up and hashing that out and everything else. The so cool. Okay. So, we got a little bit of time left. Does anybody have anything else for governance working group. Nope. Okay. Let me just pub open the issues to see if there's any assigned issues that we have not already discussed to do content tracking. Committer versus maintainer is still open because of contributor growth. We've obviously been addressing this. By the way, this whole discussion we're talking about maintainer. But the one of the things that I've actually recommended in my other documentation around this requirement is that we actually use the term senior leadership group with a bunch of specific requirements attached to that. Because some projects already use the name. I can commit or maintainer to mean something very different from how most of us use it. And we don't want to define nomenclature for projects. One of the things outstanding there is also helping with the end user requirement, which is not a governance requirement so much but doesn't really live anywhere else. The, and I still have that still on me, because I still need to talk to Cheryl about it, since she was not in the to see meeting where we discussed it. Diversity requirement again. Survey is out. But Paris isn't here so I can't ask her about closing the issue. And that is it for our open issues. Okay. Nobody has anything else. That is all of the stuff everybody has content they're working on. I will get back to everybody with the sort of draft letter to the TOC. So you can submit your revisions to it and then we can send it off as governance working group. And the the and then we'll see where it goes from there. Thanks Josh. Thank you. Thanks everybody. Thanks everyone.