 Hello, everyone, anyone else's zoom client have all sorts of fun things at the bottom of it now. It's coming here. This is your chance for a mic check as well. Check check. Sounds good. Thank you. Sure. No, like we try to be able to do like, you know, nice things to have the call for like, you know, everybody come on in. Check your mic. All that sort of thing. All right. Do I want to get started? We get 19 people on the call. This is awesome. You know, that's as good as we're going to get. So, all right. All of you everyone today is October 17th and this is a public to see meeting you've made it, which means you're familiar with the logistics and your participation is an abide by the LF anti trust. Next slide. We have several to see members present today, but we will not be making any decisions. We are going to have a recommendation presentation from the projects moving levels task force. This work was initiated through the tag contributor strategy so we thank them for facilitating this and providing key recommendations of community members to the to see on how we can improve the moving levels process. And I will turn it over to the representative from that group that is doing the presentation. Thank you. And we can move. Thank you so much Amy. Okay. The projects moving levels task force has been meeting regularly, both synchronously and asynchronously with a lot of great information and contributions across the community. Some of the major goals of this task force have been to simplify the maturity level requirements, as well as make sure that the administrative load on both the to see and the tags is not increased, but is decreased, as well as prioritizing clarification, automation and data driven decisions as possible. Next slide Amy. Okay, some of the out of scope items are. There are no recommendations on changing any of the maturity levels themselves. As well as the sponsorship process. We did not look at, and there's no intention to change anything that is in flight right now this would be net new. So it's not to complicate any of the current processes, or this projects that are in flight. Next slide. Thank you. Okay, some of the findings and recommendations. We've been talking to a lot of projects and people that have been working with the projects. It's, it was made clear that there's a lot of ambiguity, and it's causing confusion, not only that, taking up more time, and creating more of a backlog for both for sandbox incubation and graduation and creating more of over more overhead for the to see in general, as well as the projects themselves. And another key finding was that we do need to be more clear on the processes themselves and explicit and what the projects are being asked to do. We need to move through the levels. The recommendation is that a checklist based approach is put forward. And in a couple of slides will go through what that looks like. And a checklist would help the projects understand their own maturity and how to go forward and become a more mature project within the CNCF. Also, all the criteria for each level would be cumulative. When a project applies to same to incubation, you would include all these sandbox requirements, they would continue to need to meet those in order to apply and same goes for graduation. So each, each step is cumulative. Next slide. Okay, so again, we'll talk about the checklist but that's going to be in the next slide to suggestions are that a grid or checklist based approach and this is something that we are going to ask for feedback on but at least a way for projects to explicitly look through a list of items that they're required to meet and think about as they go through each step in the process, which also means that they can look forward and plan ahead to where they would like to be. For example, if a sandbox project is coming in and they have goals to eventually graduate from the CNCF, which would be amazing that they can look ahead and plan for that strategically as they're growing their community and working within the ecosystem. The intention for this checklist or grid would be that it would be shared by the TOC and the project and it would be standardized in a location where each project. There's no question on where it is. So, and that people again people know what they need to work on. Next slide please. Okay, so this is a view of what the grid based approach looks like a lot of great work went into this. Thank you to the task force. So, as you look at the grid, it was broken out into multiple sections for projects to look at, for example, application process principles, governance and maintainers contributors and community engineering principles, security, as well as ecosystem. And as they look through each of these areas, the task force has gone through and made suggestions on whether the line item is suggested or required, and then who the primary owner would be for that. This is too long to go through right now. However, this grid can be made into a checklist. And that's something that we wanted to also bring up for discussion. And the grid is probably 70 to 80% complete, which means it could be potentially sent out for project review and feedback from the community. Next slide. Okay, so major changes that we were looking at. There have been a lot of implicit requirements, which has added confusion to the projects, as they have been working through the process. So, a lot of them would now be made explicit. This is just allows projects to organize themselves in a way where it's a little bit more standardized, and it's not project by project basis, initially, but it'll help simplify the steps moving through the process. And again, it's progressive. So, by having the recommendations on moving through each level by being progressive it shows you that a project and incubation as it's moving through the maturity. So, we've seen some projects where they were more mature in Sandbox than other projects in incubation and this allows for projects to see where they really are in the maturity level. So as they move through, they can see how they are progressing. And really the recommendation is that they also have a self evaluation checklist so they can, they don't have to keep asking the TOC questions or the text questions they can go review it themselves, and then come back for feedback. I'm actually going to pause here for a minute because Josh has some good questions around. Well, Josh has a good point around here, like we had both. So, I'll let him kind of speak to us how we got here really. Yeah, no, we had a big committee on this and so we started out with a long checklist formatted document that has a lot of input on it. I don't know if we, I don't have that up on a tab so. And one of the problems is we talked about this progressive levels thing but it was really hard to visualize it through the checklist. Doug and I created a grid version of the documents. But George and I aren't finished cross checking between the two of those, because there was committee input on each document we want to make sure that we captured all of the input. And that's why we say it's like 70 to 80% on because, because we need to make sure that that everything went into both because one of the things that came clear through talk to the various members of the committee is that we need both is that some people are going to and by some people I mean including project maintainers are going to be able to follow the grid better and some people are going to be able to follow the checklist better and so we need to have both, and they need to both have the same stuff on them. Yeah, and I know George did a ton of work on that. So, let's come. Yeah, come on in. Yeah. You have a weird mic. You have a weird mic. I don't know what it is. Okay. How about now do I sound much better. Come on back in. Yeah, sorry. I'm having hardware issues. I kind of went into it. Having gone through this process before is, you know, a lot of times you don't know where you are and where you need to go. And so you end up just asking your talk sponsor. Right. And sometimes that's like a two week window to try to sneak in a 15 minute call where really, we just needed a checklist of a thing. So I kind of went in there thinking of like where, you know, what's the checklist of actionable items that I can do self service for myself before moving on. And then hopefully what we would like to do is be able to generate this checklist and annual reports and everything based off of the grid based off all of the things that, you know, over time we add and remove items that as people go through the process, we can tweak little items here and there. I hope that kind of adds a little color on it. And then for the TOC members on the call, one of the important things that the group focused on was ensuring the TOCs did still have some level of evaluation based off of their expertise and experience with projects moving levels. So the intent was to get the TOC out of the critical path for the things that the project really should be self sufficient with and capable of accomplishing on their own terms at the time that they feel most appropriate. So anyway, when they come to the TOC they are more prepared, they have a more complete understanding of where they are at from a maturity level, and that simplifies a lot of the TOC's work and doing and conducting that verification and evaluation. Any questions pausing kind of picking people up. All right, I'm seeing nobody come off mute just yet. So Karina back to you. Thank you. I get new things. You were done with that slide. Yes. I wanted to double down on the automation and data driven decisions where, as you look through the grid, what can be automated. There's also it's on the. So here's a question to there's one more slide with more questions, but with a lot of the changing and people moving between organizations. The question of whether the two org requirement needs to be changed. And the recommendation is that it could be replaced by a set of criteria that shows sustainability project sustainability and there was a very long discussion on what that means. So it does need more discussion. I know Emily, you were driving a lot of that. And then I'll highlight that we definitely didn't reach consensus on that one. So this is something that I think we need more people to be able to. That will be for largely a huge tier C conversation that needs to be informed by project maintainers and community members because we were not able to reach a conclusion. It was a great conversation and discussion for sure. So also, the governance requirements at each level need to be explicit. So that's something else that needs to be looked at, especially incubating. And then graduation. And also we looked at the what it means for each. And again, you'll see this in the grid. So later when you have time look through the grid. So explicit categorization for ecosystem security, you know, contributor, etc. Next slide. Yes, thank you, Bob. The maintainer life cycle and there's a requirement that was something that really came out that it was more of an implicit requirement and it would be great to make that more explicit again. So open questions. So the timeframe to implement. I guess I should say out for comment, get project feedback, as well as then move to adopt. So that's our question is what the TOC is thinking. And then also looking at the checklist or the grid approach. And whether both, or standardized on one. So I will stop there. So I want to open it up to questions so far I know Kathy you had come off of me earlier. I have a question on the checklist say, so there will be a self evaluation checklist. Is there a checklist available for review now. As I understand it. Yeah, it's not quite complete yet. So the task force group is still going through and trying to verify that they didn't miss any comments or areas of inclusion that need to be reflected in both the checklist and the grid. Once that's done, then both will become available. Josh and Karina, did I get that right? Sounds like yes. Yes. Yeah, the, if you look at the two documents, the state that they're in the grid is more complete with all of the criteria and has been duplicated. The checklist has a bunch of duplicates on it between the sections, but it has more individual feedback across the committee. The, so that's sort of the same sense so it's not quite ready for review yet. One of the things I wanted to do when we've actually got this fully reconciled is try regenerating the checklist with different top level organization that is actually organizing on the top level by maturity level. Because right now the checklist is primarily by section and then by maturity level. I, and, and I think that's a little harder to scan than if it was by maturity level and then by section. No, that makes sense. What other questions? George, you have a hand. Yeah, Bob, I saw you mentioned in chat about the maintainer life cycle there is a requirement. Do you have any feedback there on that on that one because we explicitly tried to include as much things that people were concerned about or doing, but weren't explicitly listed. I didn't mean to put you on the spot. Sorry. Bob may be stuck on mute. Aaron, you have a hand bubble come back to you if you can come up mute. Did you say my name Amy you're super quiet by the way. Yes, Aaron come on in. I just wanted to kind of get a feel. Could you go back to the grid. Where the due diligence. Is it clear from the community where we say the to see in the project. Are both the primary owners who needs to deliver what and ultimately how that's done. I know that that's been done different from to see representative to to see representative. Do you feel like this needs additional information to be able to clarify this because typically when you have to primary owners. That makes it hard to know. Who's doing what so I just wanted to get a feel. For what the community feels like we need to provide there to make it clear. I think Emily can best speak to that. Yeah, so the grid does not do a good job of showcasing this and I'm glad you highlighted it because there is still a fair amount of work for the to see to actually define in this category. So while the top level item of a due diligence review is a shared responsibility with the to see is the primary lead in the project is a supporting lead on that the actual production of the due diligence document. Is the responsibility of the project and the resolution of the due diligence review concerns is responsibility of the project whereas the actual review concerns come from the to see member that is the sponsor of the project. So it's a little bit of how the process kind of exists today but we have not done a good job of documenting it or clearly conveying that back and forth portion of due diligence generation where the project does a fair amount of work the to see steps and and reviews it deep dives into the project's documentation and then come back with recommendations and areas of concern for the project to resolve. It's hard to capture with the grid, but my expectation is our TOC documentation. When it is written and drafted as part of a public comment period for this will more clearly reflect that exchange. Yeah, I just wanted to point out that I think that's still an area where we need to improve and I handing this over I'm not sure people would understand what this means today so I appreciate the color on the Emily and thank you to everyone in this meeting especially contributing to that work item when it comes out to making sure that it's well understood and grounded in reality. Thank you. I have a follow up question. So is there a is there a document that you know shows you know what the project maintainers will do and or what are the responsibilities of the project maintainer what are the responsibilities of TLC that I think we have that document it will be much more clear to the project owners and TLC members. Part of that is captured with the primary owner section but the actual detailed breakout is what's missing of like what is that actually mean what is the responsibility of generating that the process of contacting CNC to make sure that the document is created in the correct drive folder so everybody has the right permission set for it. Where's that template if we're using Google Docs, or maybe we're doing PR is like the actual detailed implementation specific steps associated with those primary owners still needs to yet be defined. Any other questions so when all these documents are ready will those document be reviewed first by the TLC members, and then we open for public comments. So I think that that's a next topic area that we need to discuss is and that was an open question from the committee is what are the next steps and what are the next steps look like in the timelines associated with them. I want to make sure we come back to Bob the conversation around maintainer like no no we're tracking everything it's going to be great Bob come on in. Okay, can you hear me now. Good. I'm on my gaming PC and I don't have it set up with zoom. So, I've been on the maintainer life cycle being able to have the onboard and off board requirements have been very good like Kubernetes introduced the emeritus policy and the criteria for removing people. And that has been incredibly useful just for the long term sustainability of the project, and just making sure that the people that are actually there and in the org are actually active and contributing to the project. Adam, you had a comment in chat and I want to be able to have you come speak to it. No, I'm just ordinarily when there's a complex change between two sets of criteria would look to do some kind of death between the two and make sure I'm understanding what's actually changed and what's just being represented in another format. I think Josh explained it very clearly like this, you're converging lots of different documents into one document so what I'm trying to understand is, what are the things that just representations of things that already exists somewhere else, and what are the things that are actually changing so that. So for example, the conversation about the two org requirement is a net new change and I think that's actually interesting and probably deserves lots of conversation about it, whereas things that are just copy and paste from existing documents in this format is is not as interesting, for example, so that's just just my observation, not as somebody is not involved day to day is going through all these processes, you know it's hard to work out what the material changes are so. Josh you have a hand and I suspected answering this question. Yeah. Yeah, so, aside from the couple of things that we called out as things that were suggesting a sort of level changes. I everything. Everything else is either like original or a slight modification and something that to see members asked for during an incubating or graduating bd. So one of the things one of the things that we got as feedback from some project leads etc is that that the highly sort of interactive nature of the process really draws things out for them in an uncomfortable way. And so one of the things that we tried to do was look through for completed due diligence documents. What are all of the things that the TOC was asking for from projects that might not have been spelled out for the projects in advance. And so a lot of the reason why this is such a long list is that we were attempting to capture all those things so the projects know that they need them in advance. So from that perspective very little and this is new. Except for the fact that everything is listed explicitly. All right that's super helpful thanks for the explanation. Appreciate it. So I want to add on before turning it over to Ricardo is that it's certainly something that the to see with support from the task force can pull together because I do think having either an explanation or setting expectations on what these differences are because in the past. The to see has made decisions that are not clearly documented for why we made a decision a particular way. So having this to reflect those changes, or the additional clarity where a criteria may have been interpreted in a different fashion, depending on which to see member which to see sitting actually went through and made that decision is important and that's something that we should be providing to the maintainers. So I want to turn it over to Ricardo and then George. Yeah, so I have a suggestion about timelines to maybe provide tentative timelines. I was, we've seen some of the projects. And I think there's some questions about response from maybe the tax and the to see when you come is coming up pretty soon. So they want to move, move up to the next level like incubation or graduation or graduated and maybe specifying sort of timelines might be helpful and sometimes the tiger to see are not able to address that before cube comes. clear and understand that they don't have enough resources and so forth. I'm not sure if I understood the suggestion, can you come back Ricardo, say it again. Yeah, timelines, maybe a little bit tentative or provide tentative timelines, for example, you know we the public coming period takes about two weeks. The response from the TOC regarding the due diligence document should take about a month. It's just tentative. It doesn't have to be. So you're asking for timelines for like projects not timelines for when we adopt this. Right, right, right, right. Yeah, I think that's an open question. I think they're both open questions. I think we talked about this within the task force around why we didn't purposely add in those time constraints or time boxing each of those steps, and a lot of it I believe someone from the group correct me was around the fact that every project is different and some projects will be better and further along, and it makes it easier for discoverability of some of this content. But ultimately because of the shift in a lot of the processes that we've described here in the criteria, we don't have an initial estimate to provide until we start this. Because having a project go through into a self assessment now is going to probably save us hours later on through the moving levels process but we don't actually know what that looks like. Yeah, but yeah, that's for the project and then I thought about also the TOC and the tag timelines because the TOC is busy with many different things. So they may not be able to get back to the project or the tag may not be able to get back to the project. When a review is required, for example, the due diligence document needs to be reviewed and go through all the different steps. Does that make sense? It does. Definitely think it's something that the TOC needs to discuss with the tags for what's expected because if those timelines are passed, we need to understand what happens in that case. So I want to make sure that I've got that one captured as an action for another discussion that we need to have. Sounds good. Thank you. Josh, you had a hand. Oh, no, sorry, I just didn't lower it. Nope, totally fine. George, passing to you. Real quick, I just wanted to comment on the diff. We tried that. And what we did found when we look at the existing policies and stuff by the time we dedupt and, you know, set things that were implicit to be explicit. It almost came out like a new entirely new structure. So the way I've been kind of practicing with the document is grabbing a favorite project or something that you might see announced and then just kind of green fielding my way down down the line. I wanted to add that's, that's how we ended up kind of not being able to say, you know, these are the big changes that were happening because by the time we structured it to the end. It's saying the same thing, but it's structured different. So I just wanted to kind of mention how we, how we ended up that way. No, thank you. There's a lot of conversation around maintainer life cycle again. You had some great comments in here and so did Bob. Yeah, my comment was really just about trying to understand, like, at what point does it does an American policy have to apply. I think right now we're considering it as part of the graduation. And then Bob, because you had other comments in here as well. Yeah, I am definitely in favor of being absolutely required for graduated. I do think it actually be at least, I think it's worth it incubating honestly. But it's helped significantly with, you know, a good example is a maintainer that was with the project. It was first created, and then goes inactive for a while. And it makes sense that, you know, that person shouldn't be in an org or have like admin rights over repos or things like that anymore. And then they do go to eventually remove them. It has caused friction and conflict that has definitely gone out from the project like Twitter and elsewhere. And that has been I've seen that across multiple projects. So having that sort of activity requirement, or just some you know criteria that defines emeritus is is incredibly useful. The other problem, this is a, I'd say like a bit more of a Kubernetes problem because people love having the Kubernetes logo as a, you know, badge and they'll put it on. They'll use it in basically use it for chasing clout and having so they'll do just enough to become an org member and then do nothing. And so that is where some of the activity requirements help in, you know, dealing with those sort of situations that you don't really expect. The one problem is like in Kubernetes, we have a very good audit log of when people have joined the org so it's easy to see they haven't been active for a year. We know the date that they joined, and a lot of other projects don't necessarily have that kind of record keeping and the GitHub audit log does roll over. So it was a bit of rant but just trying to summarize the comments from chat. Anything else around maintainer lifecycle before we move on. Actually, Josh, you have a comment in here and then I'll pass it to you and then Kathy. Oh, yeah, the other thing that changing that requirement recommendation came out of is that one of the things you know we've started doing the governance reviews for projects that are entering graduated. And one of the things that we've repeatedly found is that by the time projects get to graduated, you know, most of the time they've been in the CNCF for at least a couple of years at that point. Half their listed maintainers are effectively retired from the project. And that's why we're recommending that it will be better to actually ask projects to have some kind of a written maintainer turnover process at the incubating level. So that they actually are between incubating and graduated, but they actually are thinking about hey, this person is not active with the project anymore. Let's remove them. So one thing some of the projects actually do adopt written governance at the incubating level, and sometimes written governance with some I required voting thresholds, which can then lead them to trouble if half their maintainers are no longer active. We've had to straighten that out a couple with a couple of major projects so it's just, you know, it's looking at not not both, you know, what do we want for project standards but also to help the projects themselves. Thanks, Josh. Yes, so I'm wondering what what will be the output of this. This task force. Are they going to be like, I mean, is there going to be like updated graduation criteria document or like the grade or the checklist. It's like a place documented. What will be the output. So I believe the task force and met the primary deliverable and providing these recommendations to the to see particularly around either a checklist or grid based approach the explicit definition and better clarity of the criteria and for which levels that they apply there were some shifts there to be a little bit more clear on what the details of that were for a particular maturity level. I think the next steps and task force please correct me is we need to define what's the next step from a completion perspective for this group to be wound down. We need to define and complete the documentation support for these changes where they exist, which is changes to the TOC repo. The TOC has some decisions we need to make around sustainability and openness on that to work requirements, more explicit detail on governance requirements. And the TOC needs to define our own processes, as well as making it clear in the handoff and exchange of the due diligence portions of it through that documentation. So if once all of that is done, then we can consider a discussion around a two week comment period. Josh mentions writing the self assessment guide is going to take a while tag contributor strategy started the governance portion, but it's not yet working on others so that still also will happen. And I would say is not responsible for some sections at all. Yeah. That's fair. Thank you, Josh. Hey, what other questions. So let's talk about a few things if let's let's start with Josh's most recent comment tag contributor strategy is focusing on the self assessment associated with governance portion. Does the task force have a breakout of the additional areas for a self assessment so we can turn those over to the respective technical advisory groups for completion. Let's say security is obviously going to tag security. The end and one of the things that we did not get done as part of the task force is to actually formally reach out to tech security and make sure that all of the tag security requirements are represented. I don't think they probably are not the stage. So it would be, you know, a need to make sure that all of those are represented from tech security and the parents office assessment guide. And then somebody would need to be assigned to do the process and ecosystem portions. Because that's not obviously any particular tags responsibility. Thank you. One thing that we did discuss is whether. For those sections. It'd be appropriate to send to tag leadership. For overall tag leadership review comment, and then they could be assigned. How do others feel about that? I think that's a good recommendation. Any of our tag leads on the call with an opinion. So Amy, let's let's see about grabbing the process and ecosystem sections to coordinate with the tag chairs on either creation of that checklist or identifying a self forming group to do those that self assessment for those. I want to be able to make sure that the task force is complete with what they think they want and kind of in place to be able to get feedback. So like, yes. And also, like, are we ready for that task force? Any question? Right, exactly. As we wrap things up and want to be able to then give it over to like the tag leads for, hey, what are we missing in here? What would make most sense from process and ecosystem and yes, security for tech security. Yeah, I mean, yeah, at that point, the scope kind of moves to a place where we're coming past the recommendations into a more focused. More focused things on a per tag or on a per area or domain area, which might be out of scope actually. That is good for the task force, but it's not out of scope for TOC. So agree. Yeah. Like task force, I want to be able to make sure that the work here is done. And then we kind of move forward with like the proposed timelines would be one. Yeah, Ricardo, come on in. Yeah, I think the list is pretty comprehensive. And I think, well, it's up to the task force to decide when the list is complete. But it can also be an iterative type of task. So, I mean, this is not going to be the last version. So question Karina, go ahead with. We saw the grid or checklist is, you know, 70 80% complete and we're hoping for more feedback on it. So the question for the rest of the task force right now is. Do we need to send out for review and then continue or is this where. I mean, I know this is being asked that do we hand it off now. I guess I saw that for this meeting we would get more feedback on. Is this the right approach for the, that we're looking at and, you know, getting feedback from either the community or the tags themselves on this approach. Okay. So it sounds like once the list is at 100% maybe sending that out for public comments that way we're not generating documentation that has to be changed again based off of community feedback. I don't believe anyone here has expressed any concerns with the approach that the group has taken I think it's very sound it's it's much more clear, at least to me but I'm also very close to this, having been a participant in the group. How do others feel do we want to open this up for a two week public comment period. Once it is complete. Once the grid and the checklist has been fully reconciled with the comments from the group. I actually want to put this on the TOC and tag chairs meeting tracking for Chicago because I think it needs a little bit more time to be able to kind of put the pieces together and I think being able to sit down and actually the kind of focus on this more specifically of like, would this work. What else we need to change. Emily do you disagree. I don't think so I think my only concern would be making sure that we have enough capacity to write the corresponding documentation to go with it. Got it. That isn't a couple weeks right that that yeah, ideally we'd be able to have like the like, like things reconciled. George I know you were working together on that. How do you feel about being able to track towards Chicago for this too soon. I would love to shop this around in Chicago with other maintainers I know there's maintainers that have opinions about the stuff, and it's not formalized enough where it's like set in stone. You know, and I think with having people that I feel like to come will be a good checkpoint to get sentiment around the problem does that make. Does that make sense, jive with what people are thinking. Would you be comfortable with like what we have here, being able to shop that around, or do you think it needs more polish. I'm, I've been ready to shop this thing around for a long time I think it's just a matter of getting the annoying details from Josh there as far as the normalization but I think that the major, the major strokes are finished, I think the others. Josh would you agree with that. Like I don't think this last 20% is going to be any. Yeah, like I said, it's really just reconciling to make sure, because there was a lot of input like people who participated in the in the task force really provided a lot of feedback and we just want to make sure we miss anything. It sounds like though that there are two still outstanding items that are needed for it to be fully complete and one of those is the sustainability openness to work requirements that the to see needs to provide and put on and then more explicit governance requirements. If I captured that one correctly. Well, the says one minor thing which is like I said there was a proposal of having some explicit maintain or turn over requirement at the incubating level. And that would be just a quick consensus or vote from the to see just because there haven't been any governance requirements the incubating level before and want to make sure the to see is on board with that. That would be easy. I would say that we probably want to put the replacement of the tool requirement on its own timeline. That would be based on the discussion we already had in the task force that won't necessarily resolve quickly. And for that reason, I think we want to proceed with this, have the checklist with the tour requirement on it. You know, and on some timeline that he will see will replace that to work requirements. But it might be after we publish the checklist it might be the checklist version 1.1. I'm okay with decoupling. When we do socialize it. I want to make sure that we're very clear that it is still up for discussion and have an avenue for anyone that wants to provide input to do so. Because they're talking with a lot of folks there is some strong opinions about it. All right, so we're going to decouple the two work requirements, but the grid and checklist will still include it with the caveat that it is up for discussion. And it stands to me then that we need a to see issue on our repo to make sure that we're capturing that discussion so it is held publicly and actually it's not an issue it should probably be a discussion on the to see your bow now that we have those Karina. And in order to keep it moving forward I wonder if one of the sections could be assigned to tag leadership to go through. And instead of multiple sections at one time, and then also further discussion in Chicago, just to provide a way to move it forward. Because one of the goals was also to simplify and not create more work for everybody. I agree. I think that's a good mindset for anyone that's conducting the review at and a point of discussion during cube con as well. All right, so what I'm hearing is this will be socialized with the tag chairs with it being an agenda item for the talk tag meeting at cube con. I'm feeling the sustainability and openness on the to work requirements, making sure that we have a caveat on what it is being socialized for feedback that that is still open and point folks to the correct discussion thread on the to see repo if they have input there. Did I miss anything else because it sounds like this task force will be complete. The grid is done and turned over. Did the group have additional plans for any any further work. Okay. That work anything else on this topic any other questions concerns. How did the group feel that this went. I know that was a huge ask and a lot of weight on your shoulders to do this for us and we really appreciate it but I want to understand whether or not you all felt successful and pulling this together for the community. Yeah, definitely I'll pass to you because you could comment. I was saying thank goodness for a security. Very busy. Leo had a question about time for the talk tag meeting at cube con. Amy, if you that's what an hour that we have set aside for that. We have about a half an hour so we need to be able to time box it pretty carefully, but I think like pointing over towards discussion is going to be really like the best place to be able to do. Okay. So, some time, not a ton. Do we have an agenda for the talk tag meeting at cube con already set. We do. Yes. Okay. So it's going on there. Yes. Awesome. Excellent. Anything else. It's like comment. The checklist. There, there has been some conversations on the sandbox projects being able to be more innovative and more creative. I just wanted to bring up the data to keep that in mind basically when thinking about this checklist. So when talking to some of the project maintainers to make sure that this is not very rigid. So I think we always, we always need to strike a balance between being, you know, rigid providing process just want to throw it out there. And for folks to actually keep that in mind. So good reminder. Thank you, Ricardo. I would encourage all of the tag and talk members to take a look at the checklist with that in mind as they're reviewing it before cube con and come prepared to identify any areas that inhibits innovation, creativity and experimentation for sandbox projects as we go through these environments within reason, because I do feel that there are certain conditions that make sense to introduce those constraints, such as governance, making sure that you can have a community to help with that work. Okay. Awesome. Excellent. So the TOC will create a discussion on our repo. We'll figure out how to get that out to everybody probably drop it in the tag chairs channel as well. Please socialize with your tags liaisons please remind any tag leaders that we're not present on this call to take a look. Right. Thanks everyone so much we really appreciate all your hard work and focus on this. Have a wonderful rest of your day. Thank you. Thank you. Thank you.