 All right, this works much better, at least for now. Okay, everyone should be able to see this. Hopefully, yes, awesome. Yep. Cool, all right, give me a moment. We're gonna give folks a few, a minute or two to join. Apologies for the delay, we had Zoom issues. Okay, do the music stop? There shouldn't be any music? There should be no music. Since it's gonna take like five of us to replace Amy, what tasks do you wanna assign to me for these, since I'm kind of available? That's a really good question, because I know. So on this one, you're gonna actually open up the votes. You and I are gonna talk about like how, like after this meeting, we are going to do like the votes for like over in Sandbox, so. Gotcha. With that. Okay. I'm gonna go ahead and drop camera and good to see everybody, hurry up. All right, everyone. Hello, today is April 9th, it's our Sandbox meeting. We're gonna go ahead and get started. I'm gonna apologize because I have lost the ability to see chat, so as I discover it, I will follow along if someone could help moderate for me. That would be great. So let's talk about Kairos. Is there a TOC member who has looked at this project and would like to start our discussion on it? Yes, no? Okay. But from the tag runtime perspective, we looked at it, I think maybe if you can scroll down, I think we already said that it was okay to. Yep. Apply for it, Sandbox. Okay. Do we have any other questions around Kairos? So I think one of the events on the web I mean, earlier than one of the comments that it's on board for TOC discussions or distributions more generally, but flat guy is already in the due diligence process. And I think we'd agree that we were kind of okay with that. So I really don't see why not. Kairos. Okay. So are we good to move Kairos to a vote then? Good with tag runtime. This is a project that allows you to create distribution. So there's some tooling around that. So not necessarily the same as flat car, but similar, right? But not necessarily the same, but. Yep. I think I'm definitely in favor to go for what resembles for Kairos. I think this might be a good opportunity for us to clarify TOC position on operating systems and distributions. And I think sandbox is going to be a good position for us to observe how it's doing and what is the community feedback on it as well. Yep. Great. Others, there's Dems. Yeah, plus one from me. I think one of the things that we were looking for this one was licensing issues of some sort, but it looks like they are clean. They are able to generate from many different existing operating systems. So from that point of view, they are a layer above the operating system itself. So I think, yeah, we should give them a shot. All right, yeah. Let's move Kairos to a vote. Amy and George, sound good? Awesome. All right, connects. Anyone want to start our conversation on connects? This project is returning, I think, because we've had a lot of discussion on them already. And the last review, we had asked them to talk to tag network and straighten out the issue of whether we want RPC projects within the CNCF. And so Lynn, I think, did you talk to them? Anyway, from the notes, it says that tag network was happy to accept them into tag network as a sandbox project. Yeah, I'm looking through sounds like, well, this is Nick Jackson commented on it. So we do have a recommendation from tag network then. Same thing, yep. Okay, so we've talked about this project in the past and I think the TOC had some, we've already had some conversations around precedence for technology. And so I think that we're all in alignment that this one can probably just move to a vote at this point, other TOC members. All right, cool. I think there is a discussion to be had with projects that are related to similar technologies within the ecosystem, but then choosing to have their own projects. So this is definitely they have, they have some association with your RPC and might be within the same sub ecosystem outside. And I think this is going to be the case for our next project, which is going to be Cuban, which they decided, instead of actually going with CubeSpray, they decided to have their kind of own product. And definitely this is addressed in both yours. I think the general thread here is that it is easier for community members to create their own kind of mini product, a version of a product, because it seems to be quite difficult to integrate with existing projects in their community and road map as well. So I think there's like perhaps a higher, like a deeper conversation we need to have of what we can do with these projects. I can definitely associate or join a different project which already exists within ecosystem rather than create their own mini version event. So let's, I agree that that conversation needs to happen. Let's, so connect, we'll move to a vote. Let's talk about Cubion because this is really where that conversation started. So Cubion was a project that we previously looked at and we asked the project to have a conversation with CubeSpray because it seemed very related. We thought it could be within scope. They have since provided us with some additional information. I think it's this one, yeah, this comment that provides a little bit more of like a comparison and a contrast within the ecosystem against projects like Strimsy and CubeSpray, how Cubion and CubeSpray are related but with separate focuses and separate functionality. But one does complement the other. They do work together with some, I'm trying to remember, where is it? With some differences between the two of them. So for this one, I think the project has made a reasonable case as to why they should not be included within CubeSpray. And I think that makes sense. Other TOC members, what do you think? And tag leads and chairs, what is your perspective, Dems? Yeah, I think it is good to have them separate as long as they are working together for sure. I think there was some conversation around like, can you replace CubeSpray with something else as well and give an option to the folks? I think they were fine with it, I guess, going that route as well. So overall, I think within the, Kate, Sigs, it might not fit. So it's better to have it here in the sandbox for sure. Okay, Katie and then Erin. My additional comment here is that considering how engaged they are throughout this application process, very much in favor of having them as a sandbox project because they definitely seem to be having a very clear vision for the project and a very clear differentiation between QB, Q-E-N. I don't know how to say that correctly and CubeSpray as well. So this engagement definitely puts kind of confidence in faith at least in this project as well. I'm moving forward. Yeah, just one more tidbit there is, this is from the Dow Cloud folks and they have been showing up in the Kubernetes community a lot. They were at least 10 to 12 of them in Paris. From that point of view of engagement and I think we should definitely give them a chance. Erin? I don't really think have any additive. The only thing I was gonna say is the separation is good because there are projects that we've unnecessarily grouped together in the past, just based on usage and then that becomes a detriment to them graduating. Spiffy Spire is probably the best example I can think of historically. So plus one to that piece and plus one to their effort in seeing this through. I think it shows a healthy project. Yep, Ricardo? Yeah, I just wanted to add because this was a sanctomy they replied really quickly to all the questions we asked and they were pretty clear about it, so plus one. Yep, all right. Kudos Cubion for being responsive and preventing the additional detail that we wanted. Erin, your hand is up again? Or still? No, I just didn't lower it, so apologies for that now. No worries. Thank you. All right, so we're gonna move Cubion to a vote. Awesome. Coordinator, anyone take a look at this one? Have comments, insights? Let me scroll down. Go ahead. Oh, unless the tide lays one to take over. I'm happy. Just say my comments after. Ricardo? Yeah, I think they went back and talked to these groups and there's a comment at the bottom that they say that they're okay with, yeah, coordinator should be in the sandbox because we asked them to talk to the WG batch. Okay. Other Ricardo? Yeah, I was just gonna say the same, like the project is actually quite active and yeah, it's important that they stay in touch with the different groups in Kubernetes, not only batch, but also the upcoming serving and accelerator working groups. But I think they fit here, yeah. They've been informed on the expectations for staying involved in those bodies, is that correct? Yeah, I think they even joined already the batch working group session and they discussed it there. So they're all aware of each other. Okay, and one thing I forgot to check is who are the folks from which company or companies? Do we know? Alibaba Cloud. Okay, thank you. It's from Alibaba Cloud, yes. Okay, thank you. Any other discussion and concerns on this project, Katie? So my question was, since it seems to be a scheduling specific tooling, what were their discussion or conversation kind of outlines with SIG scheduling? Either any perhaps consideration to join them or collaborate with them as well? I think that was the point, Katie. They were put in touch with the batch working group of SIG scheduling and they kind of- Oh, okay, so it's Andrew, okay, Farina, cool. Yeah, there were three people from the Kubernetes SIGs that responded on that thread, so we agreed. All right, are we okay to move this one to a vote if there's no further discussion? Sounds good, awesome. Cube Slice, multi-cluster networking for pod-to-pod communication across clusters. Anybody wanna start the conversation while I look for notes and synapses? Looks like tag network, had some recommendations. Hey, I apologize, did you want some, I can give some input on Cube Slice. Yes. I didn't know whether I was allowed to give any comments or whether it was just listening in. You are welcome to provide us your insights and observations. Oh, I apologize. Yeah, so with Cube Slice, I've had quite a good look at the project. We've done some demos with it. I think the project looks really solid. I think it's solving great problem around some multi-cluster, specifically sort of multi-cluster across cloud or hybrid cloud, which is a great benefit to the Kubernetes ecosystem. It also seems to be pretty solidly put together from a technical perspective, also from a security perspective, they've got some good stuff going on there. And they seem to be pretty engaged with us as well to want to kind of drive it forward and build community and make it a community project. So our recommendation is we'd love to see it sandboxed and yeah, we'd be happy to help them with whatever they need. Some additional color from me, at least one of the founders or the startup exec folks, they are in Massachusetts. So I did get a chance to talk to them maybe a year and a half to two years ago and kept in touch with them over a couple of Cube cons. So they have a business for sure, but they want to do this the right way. And they were talking all the right things and some of our folks ended up in, the company's name is Avesha. So all good stuff from me. I'm hearing nice things from them for sure. Okay, Ricardo, go ahead. Yeah, sorry. Go ahead. I think it looks like there's a comment from Josh as well saying that the community files look fine. Yeah, the only comment I had is that I think in one of the comments, Lynn raised a concern about the lack of GitHub activity but actually looking a bit deeper. They have several repos and the operator repo seems to be pre-active and there was a gap on the releases in the last six months of last year but actually this year they picked it up and it's been pre-active. Yeah, they said they skipped one of the releases because they had a major feature change, I think is what the comment was. Katie? Again, I just want to give kudos for very good engagement from the maintainers. I think a similar question to coordinator, is there any perhaps chances or opportunities for them to collaborate with similar clusters as well? I know it's focused on the networking component but might be a good collaboration to have with that group as well. I believe they are doing that already, Katie. I think they are showing up in the different Kubernetes six, though not in like sign networking for sure but the other ones that you were talking about. Kathy? Yeah, can you hear me? I just... Okay, I have gone through this project. I think it's a useful feature. Yeah, it's set up multiple virtual network domains for different tenants and different workers. So the slice mechanism, I think it's very useful. Okay. Nick? Well, yeah, I just wanted to add about the releases. I did give them a recommendation that even if they don't have a major feature release, they should try to create and cut regular release security patch releases. And they did say that they were going to start implementing that. That is kind of a like a weekly release or something which will just kind of help things whilst they're working on big features. Yeah, and those will eventually be requirements for them to move to incubation. So they've got a little bit of time but definitely worthwhile to give them a heads up on that now. Okay, thank you. To UC members, do we have enough information to move this project to a vote for inclusion? Yes? Yes. Awesome. All right. Next up, the Starrocks. Anybody want to start the conversation on this one? This one I think we're probably going to end up deferring because it looks like there are some open questions around licensing and it's already a Linux foundation thing but the trade, but the owning company doesn't appear to be in there or something. So what we can do is we can defer this to CNCF staff to let us know if there's anything potentially problematic with this before we spend a significant amount of time reviewing the project. How does that sound for two UC members? And also I took a look at actually the project itself is safety but the roadmap is out of date. Also no presentation to the tech storage yet. But technically I think it might be a good addition to the ecosystem because it's a database project. Okay, so Amy? I'm not sure exactly what we're supposed to do here. Like I believe that the roadmap thing we should update but like it's unclear what the request is. So for us, I think based off of the conversation that's been going on just on the issue regarding the licensing is just clarity that there aren't any license issues or conflicts associated with the project. It's already a Linux foundation project. There is a reference to a company. It's unclear how that is this just older documentation that needs to be cleaned up or is there something else that needs to be closed out before we should start looking at incorporating this project. Licensing stuff set aside, is there any technical reason or information that we are missing that would cause us to defer this? Because what I would like to be able to do is start moving the licensing questions and concerns over to CNCF staff to do as part of the onboarding into CNCF because that's the current process that we have. We can certainly call things out and make them aware and say, hey, this looks weird. But if that is the only reason for deferring a project, I would prefer that the TOC come to the technical recommendation for inclusion or exclusion, not necessarily contingent on the licensing because that's a whole nother workflow. Second reason is that they don't yet appear to have been a presentation around it to any tag. So we don't have that as a requirement for Sandbox yet. We do ask for it because it does help us in determining whether or not a project is a good fit, is aligned with our principles, aligned with the expectations and best practices of a project in that given domain area. It certainly helps and we have been returning projects back to tags as a result of that. So I had one quick question, which was on the blog post they had when they joined the Linux Foundation, there was something about talking about moving either to LFAI in data or the CNCF and saying that probably they would fit better in the CNCF. But maybe expand a bit on the cloud native part because clearly the operator is part of the cloud native area, but maybe write a little bit more about... Yeah, so there was, so Josh asked this question and they had come back and asked for the definition of cloud native, which we provided, but it seems like the only portion of it is the support for kates and containers through that operator. Geefy, if you're talking, we cannot hear you. Double mute, it's awesome. So licensing things. If the TOC votes on a project and there may or may not be licensing issues and the TOC approves for the project to be, move down part of the CNCF, is the TOC okay if CNCF staff then immediately go, nope, we're not allowing this in because there's too many, the licenses are too hot? Like are you okay with CNCF staff vetoing a TOC vote? So I'm gonna push back on the language there. It's not necessarily that the staff are vetoing it, it's more that the Linux Foundation and CNCF have made a determination that the licenses presented associated with the project are in conflict with the Foundation's charter for acceptance. Functionally the same thing. Yes, yeah, it comes the same. Let's say that that's probably not gonna play well. They're also moving to the public forum. I'm like my concern is by shifting things off the TOC and onto CNCF staff, don't get me wrong, we can do that. It's gonna be accomplishing the same thing. It's just the perception will be different and the perception might be somewhat negative. Right, which is why like, this is why I wanted to ask the question is because in the past, there is an expectation that projects that are in the Foundation have already gone through a licensing review and a license exception process and that the governing board and license committee have already done all of the research that needs to go along with it. And the TOC is providing the decision that it should be included provided those things are resolved. When projects already exist, we don't move to a vote on the project to move levels until that licensing check has already occurred and the governing board is given their sign off on it. We have not run into a situation where the governing board has said no for a project that already exists in the Foundation. So while the TOC might say that this is a great idea and we should include it, ultimately if there is a licensing conflict, that's not for us to override. Dimms and then Kevin. So I have a feeling that if we should do the thing beforehand, a license check and copyright check kind of thing, like if we'll put them in another bucket and let the CNCF staff come back to us before we look at it deeper. But just from the comments there about CNCF, sorry, cloud native definition, I don't think we should be entertaining them at this point, but I don't know if you want to make the decision now or differ for coming back with additional information. So let me go to Kevin and then I'll come back to that part, Kevin. Yeah, I just want to check because in the process, like TOC voting is the last step. Once we vote and it got passed, it's likely the CNCF staff is going to share the result to everyone. So we really need to check the license thing before we go into a new vote. Another thing is that whether we should kind of point out all the relevant questions. For example, checking license thing as well as asking for deeper collection connection with the cloud native where we go back after the license check passed. This is where we need to double check, I think. Okay. All right, so let me recap. TOC would like to have CNCF perform a cursory licensing review of all sandbox applications before they are placed in the upcoming queue for the TOC to review and make a decision or move to a vote on, is that correct? Emily, I don't even want to say that in the sense that it's okay for us to go through this process and see something and flag them for the CNCF staff to look at. Okay. Erin? Wouldn't it be nice if that was automated dims and it doesn't even come into our queue if it has that? I'm just thinking in terms of our ability to scale. Like if there are checks that can be done prior to it hitting the pipeline here. Right, I think of it the same way we think about like, hey, we should send it to the tag, right? Okay, Katie? That was precisely my comment. I think we should engage the legal committee in the same way we engage the tags. And if we think that requires an extra review from them, then we just engage them. At the same time, we cannot expect for them to do this for every single project applying for sandbox, but I think at least engaging them on this kid breakings basis will help us. Okay. So I'm hearing if in the course of our review, we find a potential licensing question associated with a project that we are going to request, we are going to defer the project from review, we're gonna request staff take a look at it. All right, Duffy? I think that would be a fine step forward. However, I do think that it is absolutely possible for legal to have some automation that describes like low hanging fruit that they could actually, that they could speak to that would be useful in every review. All right. I think we talked about the licensing portion on this one a lot. Nikita and I will take an action to have the conversation with staff to make sure that we're all on the same page for how this should work. So setting aside the licensing portion for Starrocks, there is an open question on how the project aligns with the definition of cloud native and whether or not it actually constitutes a cloud native project by our definition. Note the TOC definition on the repost on these to be updated from the governing board approved definition. That being said, given all of this, and it seems to be that the only cloud native specific ad that this has is its relation to Kubernetes and containers through the case operator. Is this sufficient for us to consider inclusion or exclusion in the CNCF? And do we have any other questions for the project that would prevent us from making a decision to move it to a vote? Do we have any other projects that were operators and we accepted them within Sunbox? Because for me here, I would say it really depends on the end user engagement. And if they would, I mean, it seems like a product which one of the installation options is for a case operator and management process can be on a Kubernetes cluster. So for me, being a case operator sometimes is not sufficient. But this is where it's very blurred. Like if we had any other projects within the same kind of thing, kind of work. We said no to operators selves. The framework is part of the CNCF but not the operators themselves. That's been our standard in the past. It's also the discussion we had around plugins for VS code. I think we ended up on the same kind of trajectory for standardizing a yes or no, but we can always revisit that if people feel like they need to be included. Correct. And to Ricardo's point in chat, Stremzi is an operator. Now that was accepted into the CNCF, not with this TOC, but with the prior one. So there is some precedence for including it but that was also, and I don't remember the timeframe associated with it. That was also at a time where we were much earlier on in the CNCF than we currently are today. This particular project, StarRox, is more than just the case operator. The case operator though is the only connection it seems to be into the cloud native ecosystem. It is still a database, an analytics database. Dems. Duffy, I know your hand is up but I'm not sure if you have a follow up. Okay, Dems. So they still haven't talked to tag storage. So we should put them in that bucket and revisit. Okay. Do I have a TOC member that's gonna volunteer to summarize what we expect the project to do before we can rediscuss and bring it back for a decision at the next sandbox meeting? Duffy. Cool. Thank you, Duffy. If you could go on the issue and assign it to yourself, that would be great. Okay, next. Cartography. Anyone wanna start with this? This self-maintaining map of your infrastructure. Anyone? Hey guys, hey, this is Lee. I just, hey, I was just taking a look at the project and cool project. It does have a significant dependent, well, I shouldn't say significant, but it has required dependency on Neo4j as its database. And the licensing around Neo4j, well, it is not in alignment with the... It's a spin dude, but they just shot down. Yes, sir. And so, and so, I don't know how much that came through. Anyway, there's one to open up a question around the, its dependencies and the licensing of its dependencies, specifically Neo4j. I think it's a good call out. Others? I guess, as long as they are using Neo4j as an external dependency, it seems okay, unless they are making some changes which will cause issues. Yep, I believe, right, I should be more intelligent about this, raise it better. I'll try to go look. I don't know that it was just a copy left thing. It was more like a point of usage thing, such that if anyone were to use Neo4j in a production environment, there's, I guess I'm speaking out of ignorance, just out of an old memory from a couple of years ago that I thought that there was a purchasing requirement or they were, yeah. Found it, I'll paste it in text. Thank you. Okay, so there is a concern on the impact of the Neo4j dependency on the project being accepted into the ecosystem. Is there any concerns associated with its cloud native fit, its capacity to be a viable project in the ecosystem or any other concerns or considerations associated with this project? I wish Matt was here. He would have allowed this one, Matt Young to watch for it. It has some cool applications for sure. And, you know, Lyft has done a bunch of nice things here. So from that point of view, you know, there were two or three examples that they pointed out which were really nice to see. So I have a feeling that we should do something like this, but yeah, Neo4j is the question there. Yeah, I don't think that we have very many projects in the ecosystem that actually fulfill this particular set of use cases. I think this is one of the things that we've talked about wanting for a while but not necessarily very clear and articulating what that want actually is. So I think this would be nice. It's also been around for a long period of time. So I think it's in a healthy position for acceptance to Sandbox and might move quickly to incubation afterwards. So for the licensing portion of it, is this something that we would like to engage staff on to help us understand any potential gotchas in accepting this project or at least moving it to a vote? So far we don't have a requirement that an end user of a CNCR project has to be, I don't know, how do we have it returned on that they should be able to use it without using any other license? I think that's probably a reasonable expectation, Erin. Yeah, I think it's a reasonable expectation, but I don't know that we actually have that documented. I think we assume that dim. So I think it's a great thing to point out that we need to improve in the documentation. I did wanna ask separately because it is a mature project, would they be better off actually applying to incubation instead of just going through the paces of Sandbox and then incubation? Or do we feel like these things that we're notating are significant enough that it should stay in Sandbox for a limited time? Good question. Nothing would stop us from having them move into Sandbox once all the licensing questions are resolved and then they can get to a point where they feel they're ready for incubation because the project has been around for a while, it's fairly robust. I've not looked at it against the incubation criteria and I'm sure the project would like to be able to do that especially since we recently clarified that. They could move fairly quickly. Ricardo, your hand was up. Yeah, I was just gonna add, I had a similar feeling when looking at it and maybe one way we can do it is just go for a vote now for Sandbox but still request an updated presentation to attack to also clarify what could be missing for incubation so that they could consider applying for incubation right after but we could sort out onboarding things in advance. Okay, so here's, this is what I'm hearing and I wanna just double check this. We would like to have the CNCF take a look at the licensing associated with the project specifically to Neo4j to ensure that there isn't any conflicts that would prevent us from accepting it into the CNCF provided that there are no conflicts. This project should be okay to move forward to a vote with a recommendation that they also present to tag security or do a refresh presentation to tag security and consider applying to incubation. Did I get that right? Dims, you're off mute. Yeah, sounds good. Okay, is there a- The only other thing I would add is it doesn't need to come to like we can do async vote on it when it is ready. Yep, is there a TUC member that would like to assign themselves and put that comment in there so that we can have staff appropriately engaged? It's assigned today I think right now. Someone else can assign. I don't think Dave is here today. Otherwise I can take it, yeah. Okay, Ricardo, if you are up for doing that, go for it. Yes? Yes, yeah. Awesome, okay. Next up, Radius, open source cloud native application platform for on-prem and cloud. Anybody take a look at this project? I have, it's quite an interesting project in terms of refocusing kind of the CNCF landscape on what it means to have an application and what it means to be a developer in the ecosystem. And I think it has a lot of potential. And I do know it has quite a bit of interest. So as far as like identifying healthy communities and momentum, I think it hits the bar on those. Yep. Karina? So what Aaron said, the only thing I wanted to at least raise is that currently it supports Terraform and Bicep both are not, well, we know Terraform, but Bicep is also an Azure project. I don't see anything right now in the roadmap for a non-proprietary project for creating resources, but I think that's just something that could be addressed in their roadmap, but I think it's a very interesting project and we liked it in tag app delivery. Kathy? This looks like a very large project. It helps complicated applications to automatically run. Deploy run on the scale. So it looks like it can combine multiple projects together, like including KIDA, including Kubernetes and CSI drivers. My question is, because it helps application to deploy run on the scale, right? So it has to define how this, to define the application, it can use YAML or Helm charts. And also, but there are other specifications too. So I'm just wondering. It also mentioned it can use it's home abstraction mail APIs from a tool like Bicep. So I'm just wondering if there are so many different ways of defining application, how should user choose? Yeah, that's my concern. But I think it's a good project. It's an interesting project. Maybe the app delivery team can help us with that, you know? So tag app delivery has already looked at the project, sounds like they're good with it. Regarding the support for proprietary or for proprietary software Terraform and the other one for Azure. In the past, when projects have come and applied and they only have one cloud service provider that they integrate with, we've had them go back and get another one or at least support for two cloud service providers. There should be, we have not accepted a project because it only supports multiple proprietary infrastructure cloud service providers pick your flavor of technology that's proprietary. So I think here it's reasonable for us to ask that they provide a roadmap for integration with other open source projects in this space. However, I don't know that we should withhold their application just because they only do two proprietary ones, Dems. Yeah, I'm good putting it to the vote and going forward. All right, let's move radius to a vote. Q plus, it's a Kubernetes operator to deliver applications as a service for multi-instance and multi-tenancy. Yeah, if you scroll down to the bottom, I think the main concern of one of the first concerns that I ended up looking at was like it's a single person repository. So we might need a little bit more community around that before they come here, I think. Okay, Kathy, your hand is up. Oh, sorry, I think I need to roll on the hand. Okay, I agree, Dems. I think that it's one person is not enough anymore for sandbox projects coming in. We really need a stronger start from a community perspective. There's also some interesting dialogue here around the difference between the enterprise, if I'm understanding that correctly, what the commercial offering is in comparison to Q plus, so a better clarity in distinguishing those and how they plan to manage that, I think it's going to be important. But given that, and given that it is a single maintainer right now and it is a Kubernetes operator, are we okay moving this project to a vote or is this a come back later when you have more people and more maturity? Yeah, I would go for the second one, Emily. Don't want to say no with a vote. It's more demodalizing then. Okay, is there a TUC member that would like to assign themselves to this to provide that expectation back to the project with an estimated timeline or specific milestones that we would like them to achieve before they can reapply? I can do this, Emily. Thank you, Dems. Q plus is going to come back later. Report, Cloud Native Application Orchestrator. Anyone look at this with recommendations. Looks like we've had a few folks comment on the issue. Similarities between three port and radius. Yeah, that's what I was going to bring up is that it is similar to radius. It's also, we're seeing a lot more of these show up in tag app delivery. And so that's the creation of the new working group for application development. Recommendation from the tag is to move this forward. Okay. Well, I had a note here about the project seems pretty young though. It's like a few months old. Unless I'm looking at the wrong place. It also seems like they have only one major contributor. Yeah, go ahead. I was just pulling up my notes on it again. Like you said, it is one major contributor and it's not as active as radius, obviously. Going from the last project could suggest that they go back for community development. But it is, it's still a very interesting project. Yeah, I had the same note. Like it looks very interesting, but maybe come back in a couple of months and we give them pointers on how to build a community. Although in this case, it's not just one. It is just like there are two people working together, Richard and Randall and then someone new just showed up and started contributing. So it's not quite the bus test. So it sounds like we would like the project to be a little bit more mature, have a slightly larger community, but not necessarily significantly larger. We also talked about whether or not they need to have more than one maintainer. And I, Ricardo, I see your comment and chat that would need to be updated if that's the expectation we're going to be setting for projects moving forward and future applications. So building a little bit more of a community around it, bringing in an additional maintainer and a minimum, as well as just a little bit more time to attract more interest, more attention to the project, grow it slightly more. Is that correct? Yeah, I don't think the maintainer one because there are three active contributors here. So I don't think we can get away with that. Okay. I would add one more thing. They seem to have some AWS specific stuff. We should get them to see if they can go beyond one cloud provider. Yes, they should be going beyond one cloud provider. All right. So they should be working beyond one cloud provider. We'd like to see the project a little bit more mature. We'd like to see the community grow slightly more. And then I needed TOC member to assign themselves and provide those recommendations back to the project as milestones for them to return later. Anyone? Okay, I will do this one. All right, we've got six minutes left. Hydra monitoring services made easy, real-time alerts seamless integration with Prometheus and GitHub actions. Do we have someone that can talk to this one? Kathy, I saw that you were assigned. Have you taken a look? Yeah, I have done through this. I think it looks like it's very early for an assignment by outside presentation. It is scoping so that we take it and there's no roadmap information. Yeah, I would suggest it comes back. And they also suggest they present into the tag observability and get the tags feedback. Yeah, I have a few more notes there at the bottom. I mean, GPL license and one commit error and... Same. Plus one to what Kathy said as well. All right, so sounds like project needs to become more active. There's a licensing question associated with the project. What other items do we need? No roadmap. No roadmap? Tag observability. Yeah, tag observability. All right, presenting to tag observability, getting the feedback. All right, Kathy, since you're assigned, do you want to provide that comment on the issue? Yes, yes, I think of that. OK. Awesome. And that brings us to the bottom of our queue for today. Anything outstanding or missing? Good job, everyone. Yeah. I do want to... Or do you want to raise your hand? Duffy? Do you want to raise one thing, which is that in the new section, maybe this is just me not knowing how to do the thing, but like in the new section, we now have the SpinCube project. And in the existing projects that are going for Sandbox, there is the Watson Cloud project. And they seem to... Seems like Watson Cloud's been in there for quite a while and SpinCube showed up like three weeks ago. And so I think that's raising some heckles. Oh, wasm... Can I just add wasm cloud to the list or...? Wasm cloud is an accepted Sandbox project already, so it's applying for incubation. Oh, OK, that makes more sense. Yeah, wasm cloud is applying for incubation. SpinCube just applied for Sandbox. That makes more sense. OK, anything else? All right. Cool. Thanks, everyone. I will see you all next time. Thank you. Thank you. Thank you. Bye.