 All righty, looks like we have Quorum, but is Alexis, Brendan, or Brian here? I don't see them. Oh, it looks like Alexis is here. Alexis, you there? Hello, I just joined, sorry I'm late, everybody. No worries, okay, so we got seven out of nine, Brendan and Brian missing. Cool. Liz, you here? I am here, yes. All right, let's slide five. All right, let's move on to our agenda and feel free to take it over. Okay, sorry, I'm flipping through, I'm on a different slide from what you were on. Okay, all right, so I guess we have a couple of new Sandbox projects to welcome. We've got all sorts of updates on like community events and meetings coming up. I think there might be a bit of discussion around act delivery and some changes in some projects, so without further ado, let's move on to giving a giant welcome to Flux and Thanos, congratulations to those two projects. Any comments or questions about those two? All right, so Kubernetes forums, I think every time I hear about these, they have a different name, but Kubernetes forums today. Chris, did you want to say something about? Yeah, sure, this has kind of been a response to, in the past, people have requested more events in kind of areas outside of the major cube cons, and so we kind of came up with a two long strategy here. One is to kind of create these, they were called Kubernetes summits, but we've renamed them Kubernetes forums to prevent confusion with the contributor summit, and these are kind of CNCF run today. Events, our kind of initial experiment with this was with the Kubernetes Day in India, turned out to be super successful, so we're just replicating it in new cities across the world. We're gonna be starting with Sol and Sydney in early December, and a couple new, actually a handful of new locations next year in South America, Mexico, Tel Aviv and so on. We're also launching something called Kubernetes community days, which will be similar to kind of DevOps days in spirits. We'll be announcing that hopefully within a month, but look forward to that news, but hopefully this will enable kind of more, events for people in areas that haven't necessarily had a cube con or have been able to attend kind of a Kubernetes or CNCF event. So quick question on these, Chris, and I can ask through other channels, hopefully folks don't mind. Where's the content for these things coming from? Is this gonna be CNCF people or locally sourced or CFPs and trying to get people to travel, that type of thing? Yep, there'll be a CFP, so you can see the link to the CFP for these on the slide there, and when we're sourcing to the best of our ability a local, locally or regional program committee. I can probably speak a little bit more to this as well, because I'm a program co-chair for this first, Nolan Sydney pair. So yes, as Chris says, there's gonna be a local committee for each event. We're trying to get about half the speakers to be kind of local for some definition of local, and the other half to be kind of international speakers and try to get some of the people that everyone really wants to see them speaking to be able to get them to travel. I think part of the reason for having the two relatively geographically close events in the same week is to make it easier for people to potentially speak at both events. And yeah, question, same talks in both locations. So the international speakers would be the same in both locations and the local speakers, so local to Korea, local to Australia and region, you know, in each of those locations. Okay, any other questions on those? All right, so I think the next slide is about the zero co-located events. Chris again, do you want to? No worries, you know, we've have a lot of co-located events part of KubeCon proper. So, you know, there's a contributor summit, Helm Summit, Prom or EnvoyCon. Some of these actually still have open CFPs, so if people, you know, have an inkling to another kind of up at bat to get a talk part of KubeCon, ServiceMeshCon and Observability Practitioner Summit have their CFP open until the end of this month on August 30th. So feel free to submit talks. There's also sponsorships open for a lot of these events. So feel free to take a peek at them based on your interests. Any questions? Cool, all right. Okay, so, new KubeNessie security, and would it publish? So I know what my bedtime reading is going to be. Yeah, it just went out today at the same time of the TOC meeting. So threat models been published, it's linked to that PR above. So this was something that the security audit working group put together through an RFP, which shows a vendor and after quite a few months of work and dealing with these issues, they published a pretty good report of their findings along with the associated threat model. So feel free to check it out. Any questions on the security audit or? Were there any high level headlines that you're aware of? For, I think there was definitely some associated CBEs, forward deemed high severity as part of the report of the 30 or so issues that they've all have been addressed that were high severity. Great. Okay. So we slightly reorganized the way that the TOC meetings are happening every month. The main reason for this is to introduce a private TOC meeting. What we actually are finding is that when the committee get together, we find it much easier to work through who's going to do what on which, assessing different projects, kind of speaking our minds about what we think about different projects and so on. And we found that those meetings have actually enabled us to kind of make progress on projects, project proposals more effectively than we've been able to do them in the public meeting. We did try to record them, but we discovered that on both occasions that we did it so far, we had some kind of sensitive discussion that meant people weren't comfortable publishing the recording. So I think we will just stick with note taking, everything is documented as we come out of these private TOC meetings. I know that everybody wants the spirit of everything to be done in the open, but I think the reality is when people kind of want to raise their hand, it's quite difficult to do in a very large public call. So I think this way we can actually be more effective as a team to drive things forward. But if anybody does have any kind of hesitations or concerns about that, do say so. So I'm just going to leave that for a moment in case anyone wants to type in a question. Thanks Michelle. And we will still obviously be having the monthly open meeting like this and the monthly community presentation of projects. The project presentations will still happen in an open meeting. Okay, oh, interesting point from Alex saying that might be a good format for SIGS too. I think if SIGS wanted to adopt the same principle in order to kind of get through the work they need to do, so long as they are transparently documenting all the decisions they make, I think that's okay. Yes, do you see notes? Yes, absolutely. I know the last one we did circulate round. I know because I did it. I think it was in the TOC mailing list. And I think I've also, if I recall correctly, I put it into the working document as well. Okay, so SIGS. So two of the SIGS are up and running and the SIG app delivery charter is kind of under review. I know there are some comments in there. It's under review. I think we've reached a stage where the people who are contributing to the setup of the SIG have pronounced themselves to be happy with it as far as that SIG goes. And now's the time to share it with the TOC and with the TOC community. So I believe Alois from Dina Trace posted it on the TOC list and some of the slacks in the last seven days. If anyone hasn't seen that, just ping and there's the document, Chris. Anyway, we can get you a copy of the doc. Right now, it's request for comment stage. So if we get the right set of comments, then Michelle and I will work with the editors of the document to get it into a sort of cleaned up state and then perhaps it can be moved to a vote. Concurrently, Michelle has been soliciting potential chairs and we are very close to getting to a vote on chairs. I don't think there's much else to add to that, unless you want to add something, Michelle, about the chair voting process. Nope, we had the forum open for quite some time. I had announced when I was going to be closed. So now it's just up to us to make sure that that vote happens in the TOC in the next week or two. Great. So hopefully come the end of the sort of summer vacation period that some people are on, we'll be hitting the ground running with an app seek that's been posted on by the CNCF TOC. Great. And I think Doug makes a good point about avoiding death by wordsmithing. We should not get too hung up about individual wordings, but we should make sure that the scope is clear. Yes, I mean, the CNCF is an iterative organization, at least on the technical front, I hope. We can always update the charter as we learn more about the space, but I think that the rough gist is there right now. Agreed. So what do you think the timeframe will be for getting a final round of comments into that and then taking it to TOC in a vote? So we're on a kind of two-weekly cadence on the SIG meetings. I think the next one is next Wednesday, I believe. We probably need to have two more meetings before we're ready to vote. So with any luck, three weeks time, three or four weeks time. Great. Any other comments about app delivery, SIG app delivery? And then the next question is about the next SIG. I think we mentioned this at the last meeting and I think SIG networking is perhaps coming together. Lee, are you on the call? Liz, quick question for you about the SIG app charter. Some people are asking about the relationship between the SIG app, the SIG app, SIG, and the serverless working group. And I cannot remember what the TOC decided. Was the serverless working group gonna be pushed under the SIG app delivery SIG or is it gonna be separate? I can't remember what the decision was. Sorry, who was asking that question? Sarah asked it on there and there was somebody else, Kimmer, who else on the dock. There are a couple of different questions about it. So I probably need to chat about this more with Michelle. We haven't really had a chance to sync up in detail. I'm happy to declare my own preference, which is that at least for the next couple of months, we're happy to put the serverless WG under the app delivery SIG just for now and then solve the problem later. I think that it needs to carry on its work. It may need to have its own home, but the TOC may need to be involved in that decision. I don't know, but I think there's no harm done in putting it under the SIG just for the time being. So it can carry on having meetings and be an official working group. Okay, so it sounds like, unless I'm gonna inject some of the call here, I'll just say that for right now, it's gonna go under the SIG. And if it's somewhere in the future, we wanna split it out. We can consider that before right now, it's gonna live under here. Is that fair? I mean, I don't think there's any particularly strong desire to suspend it or shut it down. I think that would be unfair and inappropriate. So I think that it therefore needs to continue. Therefore it needs a home. Therefore it can carry on in this way for the time being. Yep, okay. Sounds good. Does anybody object to that? Okay, I'll do it. Thank you. Completely makes sense to me. Yeah. Okay, are there any other significant points we should make about SIG app delivery before we move on to the next one? Sorry, I meant the next SIG. So I think I was hoping there might be somebody on the call who's been involved in the possible SIG networking SIG, any takers? Hey, Liz, I do not know what is up with that. So I will follow up with Liz. It's a Mac line here. Hi, yeah. Yes, I know there was some chatter about it, but I haven't seen anything concrete yet. Yeah, we had talked about it, but I have not heard from him in a couple of weeks. So I'll follow up. Fair enough. Right. Do we have anyone else who is keen, enthusiastic, burning with the desire to start another SIG on anything while we're on the topic? My recollection is that there is one, and of course I can't remember what it is, but I think there is one more that we listed as desirable. Hey, Liz, this is Jeff Brewer. There was a observability SIG. Is that the one that you're thinking about? I think that must be it, yes. Okay, yeah. I mean, I think there's a desire to do it, but nothing's happened yet on it. I think we should leave it on the list of potentials, but nothing's happened yet. All right. Well, these opportunities to formalize into SIGs are there for people who would like to do so. Okay, let's move on. Right, well, thank you very much, everyone who has voted around Rocket. I guess it's sort of public because it's here in this public call, but Chris, you're gonna write a sensible, who is going to write a sensible blog post about this? I've already started the work. I'll share it with the TOC later today, but the goal is to get agreement on the messaging and count the votes at the end of this week and publish something next week on the blog. Okay, great. I think we can see this as a sign of maturity of the organization that we're able to do this, so thank you, everyone who was involved. Any questions on that or let's move on? Okay, so in Toto, I think we pretty much reached the conclusion that it would qualify as Sandbox. I don't know if we can easily have a show of hands. I certainly think that there were enough TOC supporters for Sandbox. Thoughts around moving it into incubation. I think the biggest problem that we have with in Toto and to some extent this maybe even falls into the notary discussion that we're gonna have later is understanding who is actually using these projects. Do we have anybody from either in Toto or notary on the core? Which is not that surprising because I think the fact that we were gonna talk about it was pretty late-minute addition to the agenda, so for TOC members, do you have strong views whether we should or shouldn't be considering in Toto for incubation or should we defer this for a future call? I think Matt's comment makes sense, but I also think we need to discuss a little bit more between the TOC around what happens when your adopters are people who can't really share the details of how they're using your project or if they're using your project at all. Right, which I think is very much the situation that nature is finding as well. Yeah, I suppose the other question we might want to consider here is if a project applies for incubation level and we say, well, actually we would rather you came in at Sandbox, I mean, is there any concern about doing that? Is there any kind of procedural issue with that? Thanks for shaking your head. No, I don't think so. They would just have to agree to it and there would be enough TOC sponsors that that's it. So if they agree with it, we're all good. If they don't agree with it, then we're all good. If they don't agree with it, then that's their decision. And I think we're kind of in the middle here with this situation where I think in TOTO thinks they have a lot more usage and definitely qualify under the incubation criteria where not everyone is sold on that opinion. So I wonder whether the straightforward thing in order to kind of move forward and make sure that in TOTO is part of the sense, yeah, is to admit them as Sandbox and then say, let's have another review of incubation status. Yeah, as long as there's enough sponsors. So happy to do that. Yeah, I'd be prepared to sponsor. I don't know if there were other potential sponsors. I would also sponsor. Okay, duly noted. Okay. Congratulations to the entire people who are not on this call. Do you want to know how to do Sandbox? We should probably ask them first. I'll follow up. Thank you. Yeah, okay. And Dan has just made the point in chat that Harbour only spent three months in the Sandbox before incubating. So yeah. Okay, let's do that then. Yes. So I guess I can't remember the name of the person who had raised this issue about whether notary should or shouldn't be in kind of archived status or graduation status or whether it's current status in incubating is purgatory. I have views, but I'd love to hear other people's views. Is the project mature enough that it's starting to stabilize and doesn't need a large number of committers to add new features, but instead to keep it going in some kind of maintenance mode? I believe that, and I haven't read it, but I did see an email come through. Yeah, so yeah. So it would be nice to get the thoughts from people like Justin who's a maintainer of Notary. I do think he's widely used. I think there are a significant number of proud native adopters who are using Notary either as part of Docker Trusted Registry or through other services. I believe there are significant numbers of users of it, but I think it's one of these people who are difficult to get documentation of how many there are. The next slide shows a response from Justin, who couldn't make it the meeting today, but wanted to forward it along to folks who are maintaining our point of view. I would also say that, and correct me if I'm wrong with Rocket, it was clear even for the folks who were on the hook as maintainers for the project that they were moving on and the project itself was sort of opting into this archiving process. I think we're sort of on new ground here when we see somebody from the outside essentially coming in saying, hey, we should archive this project. I think that's an interesting development. I'll just put it that way. When was the last time we had maybe like a project review for Notary? Is that on the books? Does anybody have that information, Heidi? I'd have to go look it up, but it's been a while. Okay. Yeah, I know it comes up more in my conversations with folks these days and since the whole, there's more discussion around securing the software supply chain. So, I was surprised to see that comment. But I think a review of the project would be really helpful. Yeah, I could schedule that, no problem. I think that makes sense. Yeah, let's do that. Yeah, so hi, I'm Brandon from IBM. So we use Notary as well, but we've also ran into issues with being trying to upstream certain patches. So what we do is actually we have a different set of patches that we apply for production. So we definitely think the technology is really useful so that maintenance is a little bit of an issue right there. Liz, you're on mute. I think let's just give them a chance to make our case at an annual review and then we'll kind of go from there. Great. I do think that the implication that commits is the be all and end all of whether or not a project is active or not is just not, it's not accurate. Okay, let's have an annual review for it and move on. Okay, this is good information that the next community presentation includes the tough graduation review because I think this is another case where we have struggled in the past around what the definition of graduation means for a spec project. So I think we need TOC members. Let's all kind of get our thoughts together about that ready for this graduation review. Okay. So we did in the last private TOC call that I mentioned, we went through quite a lot of the items on the backlog and made progress on the several of them. I think we probably need to go through those PRs again on our next meeting and figure out whether some of these are now ready to see. Some of these I'm pretty sure we've asked the project maintenance presentation for the relevant SIG. Some of them, I think the relevant SIG is in creation. But I think we are making some progress through this backlog, which I am determined we will keep up. Chris, what did you mean by what to draw? That's basically when the TOC will be comfortable to say no to some of these projects. So say one of them, you're like, you know what? You're not a good fit for a CNCF or come back later and essentially just get them a final response. Yeah, I think as also part of this process, we have started work on documenting the process more carefully and having a flow chart of what projects need to go through. And I would really like us to get to a position where we can put time frames on that, set expectations on projects. I think getting that flow chart and that documentation in place is very important and important that we get it right, yeah. Do any TOC members want to flag anything about those backlog items or any news or? I'm interested in the operator framework personally because I've been working with them more recently and also because I've been hearing more about more questions around how do operator, like where do operators go? Should they be in the CNCF as part of the home community? I also get questions around how operators can be packaged and how they relate to the homework. So I just think that that's an interesting topic and so I'd be interested in seeing what they have to say. So I agree, Michelle. And I also think it's worthwhile for us to tease apart the idea of operators and how we actually approach those from the TOC point of view from the operator framework, which is a specific sort of toolkit implementation of this and also separate that out from the operator hub, which is a red hat sponsored site that doesn't own the definition of operator necessarily. And so I think it would be helpful for us ourselves to actually bring some clarity across those different things and not conflate them. Yeah, absolutely. And there's more than one toolkit. I've been working with the operator framework but I've also heard about PUDO and so I'm just really curious to see what this landscape looks like and see if we can help bring some clarity and light to the space for that. Agreed. One of the things that it might be useful to actually do with this backlog is to, if there is an appropriate SIG to actually have us mark which SIG we think actually should be helping to facilitate guide, prep sort of standard set of information around these things. Absolutely. Yes, I completely agree with that. I think for some of them we pushed the kind of, the next step to say, please go and approach the SIG about a presentation to them but perhaps we should also be assigning the issue to the SIG in some fashion. Liz, should we just discuss maybe the mechanics of how to do that in our next meeting? I think that would be a good idea. Yeah, because we already have this kind of backlog for the TOC, we could be, yeah, at least labeling them per SIG and we need somewhere to make sure the SIGs are aware of that. Chris is suggesting a new swim lane for SIG review. Yeah. Michelle or Alexis, do you see operator framework and QDO and the like as something that you would be discussing in SIG app delivery? I do. And we haven't formed this SIG exactly yet and it does look like it's gonna be a few more weeks so I don't necessarily know exactly what we should do here. I don't know. I mean, it'll be a nice surprise for them. I think it's implied in the discussions which are in the charter around the use of the very large document that Gareth Rushgrove and Brian Grant created which has about 95 different projects which all aspire to solve some tiny little problem in the app dev space. Now, obviously most of those are not used by many people and are probably not gonna be used by many people. However, I do think one of the jobs of the app delivery SIG should be to provide a report, perhaps a white paper in a landscape on at least some of these projects and what's important so that people can understand that Kudo and Jasonnet and the other thing and the other thing actually solve different problems or not as the case may be. So I think it'll come up through that process. That would actually be really helpful and I slightly fear that we might end up, on the one hand we've talked about the Cambrian explosion of new projects coming into the sandbox, but is there a risk that the first end projects that come in that make their proposal, we kind of go, yeah, why not? And then after a while we get project fatigue and kind of go, we've got enough of those but maybe we haven't hit the right ones. Yeah, it's kind of all emotional labor really, that stuff. I mean, there's a feral environment out there. I think the best we can do right now is give people a picture of what's going on and try to sort of start to make some sense of it. I would say that this falls more on the side of frameworks rather than individual operators though. So I don't think it's directly speaking to the quote unquote operator problem that was brought up earlier on the call. Cause I think that's about the fact that there could be one or more operators for X where X is a technology that you may wanna run inside Kubernetes, which of course opens the door to a colossal number of values of X and therefore a colossal number of operators. I'm happy for someone else to solve this problem. But as far as the app delivery sig is concerned, at least showing people that Kudo lives here and this other thing lives there would be useful. Well, and if you remember the history of the operator framework, it didn't really originate from Red Hat to Joe's point. I mean, it started at CoreOS and it's serving at CD, Prometheus and Vault as its first three operators. So I think it's important to know that it's really rooted in fundamental operation of deploying things that are complex within the Kubernetes landscape and not something that Red Hat went and cooked out by themselves, so I just wanna make sure. That wasn't what I was trying to say. What I'm saying though is that we need to separate and I think this is reiterating Alexis's point. We need to separate out particular frameworks like the operator framework. The idea of an operator and which operators we accept as projects into the CNCF and that really speaks to like the Kafka operator that we've been talking about. And then sites like Operator Hub which is a Red Hat owned, IBM owned property that helps to actually sort of expose these things. And those are all separable things that we should look at and talk about. And I think that it's easy to conflate those things and I'm just saying that we should make sure that we view those as separable topics. And so, yeah, I agree. And so do you see like the different iterations of operators in their formal presence are something that we would have as separate projects in the CNCF then as part of the SIG apps? Is that what you- Yeah, I think each operator like the question is, is that each operator is a project in and of itself. It has its own lifecycle, it has its own releases, it has its own community, it has its own bug database. And so we should view those as individual independent projects. So if we end up with like a FUBAR operator for a project and project FUBAR doesn't want to own that operator for whatever reason, then I think it's reasonable for us to, assuming that it meets a certain bar for us to have that be a CNCF project. But that's different than the operator framework, which is really a framework in general. And I think we need to view that within the set of comparable tools. And then also to Alexis's point, I think having the app delivery SIG help map out these different options is great because I think that's a good first step to actually sort of like, how do we actually track these things? Maybe we add these to the landscape. I don't know, maybe we create a new landscape around these types of tools. But there are also different audiences here. I think one of the things that I'd love to see get started in the Kubernetes project in general is the idea of an SDK, right? We don't actually have SIG SDK or something that's developer focused in terms of actually building up an experience for developers. And I think the operator framework and cube builder start to get at that. That's a different issue than tools that are completely config related. And so I think teasing that apart is something that's worthwhile for maybe the app delivery SIG to do also. Yeah, and I see it as an overlap as well. Cause if you think about one of our first things we accepted into the CNCF or storage as Rook, and that's completely operator based, right? So sometimes it tends to fall under not just applications in particular, but a little more overreaching than that. So. For sure. Yeah, so I'm not against having operators be in the CNCF. I just, what I don't want us to do is say, oh, it has operator in the name, let's just glom it all together, right? I think, you know, we need to make sure that we piece this apart. Okay. I think I have similar concerns that, you know, there will be some operators where it feels like a good fit for CNCF or it feels like a good fit from an exploring whether operators even work in that space. And I think Rook might be a good example of that, you know, is an operator appropriate for storage. Presumably that's a kind of experiment that Rook is, you know, has undertaken. But I wouldn't like to see us having like 500 operators for every single possible vendor. Yeah, I think, I think there's two different ways of looking at this. So one of them is there are functional extensions to Kubernetes clusters, which an operator happens to be the correct idiom to use for making them work with Kubernetes. That's, and that was actually pioneered as Erin said by Brandon and the folks at CoroS. And then a few other people too. And then there's the other phenomenon which I was talking about, which is that there is a systematic and growing proliferation of operator for X for any X that you can think of, which could cause, you know, tremendous confusion as well. And I think it could should be ideally handled in a different way, perhaps in the Linux foundation or somewhere else. Finally, I think there's an element of, you know, I don't personally feel comfortable saying, hey, the Kafka operator should be done by Confluent. I think that that is gonna cause other kinds of problems, which I probably don't need to explain. Anyway, Michelle was raising her hand. I'm patiently waiting. You can finish, Alexis. I finished. Okay. All right, yeah. I just, I'm excited about this discussion to happen hopefully in SIGAP delivery as well because there's some prior art here. So Helm also would fall into SIGAP delivery and we have a lot of experience from Helm Hub and maintaining charts. And so charts, a chart is, you know, application specific software that runs in Kubernetes. And at first we thought, hey, let's put these charts in a community repo so they're easily accessible, easy for people to just grab something off the shelf and run that. But there's a lot of issues around that, one being just maintaining these charts and having them in one central location is really difficult. And there's a huge scale issue there. And with operators, with Helm, we decided to go with Helm Hub and really encourage people to write their own charts and maintain their own charts. So as a vendor, you would maintain your own chart, which is kind of a specific way for you to run your application. And I think there's some similarities here in terms of how, where operators should live and this whole conversation around the operator landscape. So I think that, and I would encourage, you know, the vendor that is most associated with that operator to maintain and host and house that operator as well. But again, that's my personal opinion and I would want to have that larger discussion in SIGAP delivery. That's an example of the type of discussion I'd like to see. Right, so in the SIGAP delivery kind of plan of action, this landscape portrayal is quite high on your list of priorities I've taken. I believe so. I think that sounds very useful indeed. The other one that's come up a fair bit, and I'm personally supportive of, is something that starts to talk about what are the quote unquote delivery patterns? You know, how does delivery happen? There's lots of discussion of blue, green, AB, canary, staging, promotion, pipelines, yada, yada, yada, yada, yada. There could be some useful work done around that. What is the difference between deployment and delivery, for example, et cetera, et cetera. But yeah, the answer to your question is yes, it is high priority. So I believe there is a section in the charter, if I'm not mistaken, that kind of gives examples of work that SIGAP delivery is interested in working on from the get-go. So this is something maybe we should add to that list. Within the interest. Anyone? Don't all shout at once. We have a very quiet TOC community today. There's 53 participants on the call, and not one person is volunteering for what should be a really exciting opportunity to show everybody that you're really exciting to work with. Should I scream a little bit? No, no, no, just put up your hand and say, I'll do it. Anyone? Doesn't have to be today. I mean, you could come back in a week and say, I've thought about it, and I decided this is a really good thing to help with. And they could do that by coming to SIGAP delivery. Yeah, or just pinging Michelle or something of that form. There is a SIGAP delivery SIG list, and there is a Slack channel. For those who don't know that, they are both exceptional ways of communicating with the group, and not with everyone at the same time. Great. Joe, did you wanna talk to this point that you've made a couple of chat comments about SDKs for Kubernetes? Oh, I mean, no, this is just a recurring topic for me is I think one of the things as we think about a platform, when a developer approaches a platform, what they wanna do is have the tool set that says, here's how to approach this thing as a developer. And I think we have a bunch of that stuff that's sort of organically sprouted around the cloud native ecosystem, but it's not something that's curated and packaged up for a developer facing audience. And so inside Kubernetes, I'd love to see client go be more accessible to developers because right now it's hard, but I think that also starts getting into the operator framework. It also starts talking about like for projects that actually have multiple sides, both the operator side and the developer side, how do we actually represent the developer facing stuff on that? And do we actually start building across projects sort of SDK across this stuff? It's a bigger discussion. I don't think we're there yet, but I think it's something that a developer focused effort is different than an operator focused effort. And it's not something that we spend a lot of time on as a community. Is it something that the kind of Kubernetes side of the house prioritized or maybe not so much? I'm guessing not so much. I think there's work to be done inside of Kubernetes about how we approach this. And I think that's a separable discussion, but then I think in the fullness of time having it, so like, hey, I'm a developer, I go to the CNCF website, I see all the projects, along with that is a pointer to documentation for operators, documentations for developers. We might have a landscape saying, well, here's the sort of the rust language bindings for at CD, right? So like, there's a common rhetorical explosion around this stuff. How do we actually start getting a handle on this and really providing the right input there? I don't know, it's unformed thoughts, but I do think that there's a missing aspect here, which is the developer facing stuff. Yeah, I agree that it does feel like something of a whole right now, but it would be lovely if we had volunteers to fill. As Tim said, we need volunteers. I mean, this area is one which we've been talking about for a couple of years now. And during that time, it's been consistently agreed that it's an important area, but it's also been consistently agreed that the participants in the community don't feel they have enough spare bandwidth to start putting new effort into this area. So we might just have to wait. We can't do everything at once and we have to focus. Fair enough. All right, seven minutes left on the clock. Do we have any other areas of discussion or any other Q&A that we should cover? That sounds like silence. There's been such a quiet meeting. I guess we can all have six minutes back in our lives. So, take care all. Bye bye, thank you. You're welcome. Bye guys.