 Hey Emily good morning. Hey, how are you? How are you? How are you good? Sorry? I was just Chow with somebody doors Hi Dawn. Good morning. Hey Dawn Good morning greetings. We'll give it a few more minutes to be able to come on in Hey, we've got tag updates my only question I'm looking at the rest of the group. Tag app delivery. We have anybody here for more delivery? I was going to skip them. It's also like if you're not here, please raise your hand. I understand however That was my one note as far as procedural stuff this morning. We'll give a few more minutes for Dim's folks to be able to come on in Greetings. I Had a mental note of like when we hit like 25. I was gonna pick us off anyways and Dim's happened to be 25 So there we are Welcome you have made it to your October 4th DOC meeting rock and roll From a land interest policy notice. Good to see all of you You've made it here or you're watching the recording one of two DoC members gonna be tracked over in the working doc and here's our agenda I know that there's been some conversations like you know about other things to be able to discuss We will drop those into questions and happy to be able to like take questions and chat as we move along in here So I got updates. I'm gonna pass us to tag storage and I know you've got a lot in here. So take it away Okay, yeah, so from tech storage We had Vitas EDCD Lanjorn Rook presented at our tech storage meetings Clownity PG also presented One thing we discussed in our last meeting is that we want to come up with a Use case template based on our CNCF storage landscape of white paper So in that paper we discussed what are the search attributes and how different storage layers affect those attributes so having some real use cases and connecting concrete search projects with What we described in that white paper will be useful so so we're thinking we want to ask projects to submit a PR to fill in a template once that's ready but also ask them to give a presentation to the tech and and those will be the use cases will be in our tech storage repo and projects It's not just a CNCF projects. It can does not have to be limited to that Any cognitive storage projects can can be included And also because this information will be provided by the project maintainers So we're going to add a disclaimer saying, you know, this is a community maintained use cases So it's not like we are Recommending this project for anything, but it's this is community to maintain so we'll add a disclaimer that like that. I'd like to see if If there was any concerns from you see regarding this I've tracked one note in check because I wanted to make sure we're limiting it to open source projects, but not CNCF Right Okay, just wanted to make sure it was like the I think that sounds fine. Okay, so if we want to go beyond see the open source then that's yeah, then we will have another discussion If that I agree that is a good, you know, boundary to do Okay All right, cool And other than that, yeah, I have a lot here so open EBS So I think this incubation request is still ongoing and there was some concerns regarding lack of maintainers There was an issue open for that. I believe the team has been trying to address those issues And curve we so they presented a tech storage also to see voted for that it passed the majority I believe it's still not included it because they still need to get this license issue resolved And and then Karina they presented a tech storage We recommend for sandbox One second sure Amy who's who's lap is it on right now the license exception license exception is over with governing board they're actually included as part of the sandbox so do not hold up on that one like it's something that we're working at as part of onboarding so I appreciate it coming up in here we will work on this sovereign governing board Okay, so we don't have any action nothing for you all Thank you for reminding me but like it's fine Okay, okay, I just noticed that they are not it says it's passed but it's not they're not included. Okay, all right. Got it. Thanks. So Karina basically it's so since we recommend this basically they will be included in maybe future rounds of the voting then for sandbox. Yeah, so next time we take up if we do it like every month every month or so. Next time we'll make sure that we talk about Karina first before we go to the other ones. Okay, thank you. Let me check to make sure they've actually reapplied because if they don't reapply if we're not going to be able to remember right I don't I don't see them yet on the list so Karina if you're out there please reapply thank you. Yeah, just tell them to reapply please. Yeah, I will pin because last time I think we basically just tell them that we will look at their presentations and get back to them so we also have not told them that we recommended the sandbox so I will send them a note asking to reapply. Okay, yeah so other than that I think there's like we already talked about those white paper so there's no new update since our previous update. I think I'm all set. So I did have a general questioning. How, how was the, how are, how is the tag, helping with working on the CSI specifications themselves. I would say that somebody wants to propose a change like is it still the same process, you work on the specification part first, make a change and then. How do you roll it out. CSI. Yeah, CSI but that's not under the tag right. But most of the people in the stack end up doing a CSI implementation right. So I think that's mostly in the six storage I think in, in tech storage we're not really focusing on CSI itself. Okay, right. If someone want to propose a new change to CSI, how does that go through. Oh, yeah, so basically, normally people will go to the community sync that happens once a month. And so people normally go there and you know present. And then they can submit a PR, well actually, you know, now I have to have a PR there. So the PR to say I want to bring in those new changes and normally they would ask you to. I can also explain what is the overall workflow and not just the CSI part but also like from the normally Kubernetes side right. Right. It's better to have a cap to say how are you going to use this new changes you're adding to CSI spec. And then going through the reviews. Yeah, and then, you know, once it's passed, then that can get merged. So right now we actually have quite a few new things, pretty big items actually right now. Yeah, we're trying to yeah we're trying. Yeah, there's a, I have a proposal for what a group and what a group snapshot. So that's a proposal in CSS back knows also kept in Kubernetes upstream. There's also another proposal about chain block tracking that also has a proposal on adding some new things in CSS back yours also a cap in Kubernetes upstream. Yeah. Yeah, sounds good. Thank you. Moving on to security. Hello, it is me today. Excellent. All right. And either I'm frozen, or you're all frozen, or something happened. Andy has unfortunately been experiencing network issues today. Okay. I will let you be back. Thank you. Everybody involves and they must one. Sandy back. No. How does this sound. Much better. Thank you, Andy. Okay, sounds video maybe. I do apologize if I disappear again, I will cede. Thank you. A huge oceanic well thanks to everybody who has helped set up cloud native security con. This is the spin out event from the day zero and they minus one events at cube con. We will have a multi track two day events in Seattle in February. And then there's a proposal to intertwine the same kind of talk and track titles into a security village in the main cube con event to replace those days zero and they minus one. That's usually exciting and very pleased to be involved. Then the work we have been undertaking. There is a supply chain security survey that has gone out. This is looking to understand where we best focus our efforts for any future recommendations that the group makes by understanding what projects or which projects are in use. We have seen CF projects of what type of build systems, what type of tooling, how people are looking to secure their supply chain, and indeed, what does the supply chain mean to various people. People consider themselves producers or consumers primarily that it's kind of understanding. Another presentation from self assessment from Cube Edge, which is served in the way, and cloud nature security controls. We're looking to map recommendations to ecosystem tooling in order to provide recommendations and also to make clear what options are available for people to choose for their various levels of risk tolerance. So the cloud nature security white paper is undergoing its third iteration. The, I apologize, actually lost to the slides but there are some notes as to what that actually is in their brand and if you don't mind picking that up for me in a second I finished the lightweight threat modeling process. So we're looking to expedite the sort of growing number of projects that are looking for that security self assessment and threat modeling. A working group has put together a rapid risk assessment based documents, essentially a questionnaire that is modeled after the trail of bits audit on Kubernetes itself. So we've expanded and modified the documents somewhat. The goal here is to be able to work through the threat model for an individual project within one to two working group sessions. So scoping the thing narrowly time boxing it and learning the barrier to adoption of the barrier to entry for new security threat modeling contributors. That is a personal passion and very pleased that we're moving forward with that. We are about to kick off a zero trust working group that is essentially looking at how we make recommendations that respond to some of the papers, some of the work coming out of this. And some of those standards that are turning up around zero trust in general from the US government. And finally the security reviews. You see to failure flux multi tenancy, they've performed a self assessment, and that will go into threat modeling. I'll go and cube edge. The proposition is to use that lightweight threat modeling process on the flux multi tenancy audits as the first guinea pig if you like the thing. That's all from me. Anything else from you Brandon. I guess I can. The V3 white paper you're talking about just now. I think one of the two main focuses, adding in content on confidential computing, as well as taking some of the, the content that that we've written out as part of the serverless working group and just integrating that into V3 instead of having a separate white paper. Other than that, I think just just a quick note on the zero trust working group that we are spinning up. I think one of the, the, one of the issues that we're trying to solve amongst the whole list of misconceptions of zero trust is like, you know, a lot of times people are still thinking about parameter security. And I think that is kind of a lot of the term parameter security encoded in a lot of security and compliance documents. And that proves to be very difficult for zero trust adoption that seems to be a conversation. So like, okay, what are you doing for parameter security, but I think that the idea of parameter security just like complex with the zero trust model so that's one of the goals of that that working group that any questions from any QC members or other people. I think I had a question on the ongoing security reviews. Is there a process that's published that, you know, different projects can leverage for being ready for these security reviews. You know, just to just to make sure that while you're going through again incubation as well as graduation, some of these requirements are upheld by the projects, you know, via continuous security integration or otherwise. So we have a process that projects can come in like request assessment and like we are going to put a link. Oh, thank you, Raga. On like, okay, we need the self assessment document to be created by the project and then we have someone review it and this whole process around that we have a key of projects that doing that. So the thing that we don't have like an official mapping of like, okay, if you're sandbox process project, you need to do a self assessment or so on. The general ideology we have usually is for most projects that going for incubation at least having a self assessment which is part one of the review is something good to have. That is, of course, according to kind of the the analysis of the, the, the TLC sponsor that thing, okay, this is a critical security infrastructure project, and therefore should require a security review. I think that's so in the general rule that we kind of try for those incubation self assessments graduation. We want to talk about the full review and you know we're doing that for our goal right now is just completing that. So I'll add on there. Any project within the CNCF sandbox or incubation is more than welcome to complete a self assessment. The self assessment is set up in design to assist projects and understanding more about the security and the architectural design of the project itself. And to kind of give them more of a security mindset and a lens around any future development and ongoing work within the project. It also is incredibly useful as an initial set of security documentation for any potential adopters to go through and read and understand kind of what the security considerations the project has already undertaken any kind of security features and functionality within those projects. So it's something that I would personally strongly recommend all projects take a look at and see if it's something that they want to keep within their repo or file as a PR against the tag security repository. That way they're centrally located and anybody can go and access them and they can link it back in their original docs. Emily and Radnam thank you. I mean that's very helpful because you know a lot of, for example I work on open telemetry and you know, given it's very large project. There have been many, many requests over time for, you know, from users who are using or developers who are using you know, contributing to open telemetry to have security reviews and depend known risks and and dependency on dependencies, especially right and that's something that typically is not instrumented on the projects but you know could be actually built out with a continuous security pipeline, for example, so again some of the practical aspects might be useful but I'll take a look at the assessment so thank you for the link. The main thing that I was like, there's so many things happening, do you have enough people to do all the things? That was my question to you all. More people would definitely be helpful. I think we, especially in the area of security reviews, that's an area that we've had a little bit of a retention problem because there's a pretty involved effort. I think we're trying to find ways to do this. We've talked about, with Emily, about you know having badgering and things like that. I think that will be helpful. But I think all of most of the projects I would say the reviews are the ones that does require a good amount of effort and has a little bit more of a sustainability issue in the long term. Thanks, Brian. Nothing else will move along. Runtime. Hi everyone. There you go. Yeah. Hope everyone is doing great. Okay, so tag runtime. We've had some presentations from different projects in the containers and runtime space. We have one coming up in our next meeting. It's called Lima. It's Linux virtual machines. It's basically kind of like a container D for Mac. There's a way to run container D on a Mac, which is kind of something requested by developers. So excited about that. They're also applying for sandbox. I believe. I don't know if they can accept it yet. They're in. They're in. So another Air Sandbox project and you haven't come with the Sandbox project. Awesome. And in terms of workloads, we have discussions with this project called WASMI. And it's basically a web assembly interpreter. So we have a discussion going on with them. Hopefully we're going to have a presentation from them pretty soon. And hopefully we have more involvement from them. There's another project called CVL Mariner. This is a common base Linux distribution. It's from the folks at Microsoft. It's a distribution used for edge type of workloads. It's similar to some other projects that actually offer container only Linux distributions, kind of like flat card. We're also excited about this. So we reached out. Hopefully we have a presentation from them pretty soon. There's also a discussion on standardization of the out of memory communicate kill communication between the Kubelet and the runtime. This is going on between tag runtime mailing lists and Slack channel and Kubernetes signal. So hopefully we'll see more progress there. So we're just going to be there just to help out in any way. But we're actually monitoring that development. And we'll be here just to help out. And maybe possibly, you know, if there's something that kind of fills in within a working group will also help out. Also, we have in a different scope of project open policy registry. This is project related to security. But also the interesting part is with tag runtime or relationship with tag runtime is that it is using OCI open container interface to store OPA policies and we have a presentation from them in our meeting on October 20. And finally, on some activities with within the tag. Our batch system initiative working group finally got approved. So excited about that. So folks on the working group are starting to make some progress and do some work. We also have a keep calm North America in person session on Unicernal and Unicraft is actually going to be given by Alexander John, I think he's on the call now so excited about that too. And we continue to have conversations and interest in the community about having a working group related to Unicernals, as well as a working group related to Web assembly. That's all the updates. Happy to take any questions. If you have any. Thank you. Thank you. Right. Seeing no questions. In chat or otherwise, we'll move on. Thank you much take runtime. Take observability. Hey, hi everyone. Good to meet everyone today. Just wanted to give a quick update on all the happening said the observability tag. Lots of activity we first of all, finally have a new logo. So we all as a community decided finally, and picked the, the owl and and it's a cute one. So good to good to find me. You know, be consistent. Lots of activity around, you know, throughout the quarter on different projects as well as different initiatives. As you can see, there's a lot of discussion that's been happening in the community as well as work around interoperability of existing standards in observability, especially with the open telemetry and Prometheus interop discussions that are ongoing in the Prometheus work group interoperable group in hotel open telemetry and and especially there's a lot of work happening around the advanced histogram support, both on the Prometheus project as well as hotel. So fair bit of work and discussion around there. There's also hotel collector, which is the main collector agent that open telemetry produces fair bit of discussion around garbage collection configuration management optimizations you know needed, because as tracing and metrics support gets completed tracing is already stable. There are a lot more users who are starting to use collect the open telemetry collector for collection of telemetry data and performance and as well as seamless configuration management becomes a large issue there right so again good discussions around that present cons, etc. Another area that's been pretty popular around the discussions and pretty much you know we've covered a lot of the reviews is the open telemetry enhancement proposal for adding profiling support in open telemetry. And that's pretty exciting. It was in discussion that originally started in the in the tag and then kind of evolved into a proposal which has then been submitted to the open telemetry specification for addition. So there's ongoing work happening on a hotel, which then supports you know interop on profiling as well as full support the spec. So the other areas I'd like to call out again and then you know we had a full set of meetings this quarter so super excited about that is starting to think about how we can promote more collaboration with Kubernetes instrumentation sakes and others so that there is continued progress on integrating and providing more telemetry from the Kubernetes layers and being able to instrument with different API is that a stable hotel especially as well as other projects within the observability space for Kubernetes instrumentation. I had actually three other initiatives and I'd like to call this out one is the ongoing landscape graph work that we have been working on and some of our contributors who have really done a fantastic job on kind of building out leveraging some of the graph mesh modules but you know really building out the relationships between activity projects within the observability projects but also you know working with the contributors sake and the security sake to map out further dependencies and this is a project that is ongoing. And we'll continue we'll continue to keep giving an update. The other area that I'd like to call out is that there's a fair bit of work that's happening around the cortex project health. We've had discussions with dims as you know, leading that from the to see as well as working closely with the cortex project maintainers to be able to then provide feedback and report back to the governance committee as well as the to see. And this is something again that we've made good progress on and I'd like to you know again if you want to follow details the issue is right there. And please feel free to kind of dive into that. Thank you, folks updated as we make, you know, reports and write, you know, the findings down but we have a good update coming in from the cortex project at this point and there are more maintainers who are getting involved in being able to contribute to the project so that's, that's exciting. But there's still work to be done there, obviously. A couple of other areas, of course, we continue to have good presentations in the tags and discussions around new open source projects, what he goes was one of the projects that was, you know, discussed and there was a technical walkthrough on it. We also started a series of observability expert speakers coming in speaking at the tag and that's, you know, pulled in a lot of interest. And Joan Jones, who was presenting on evolving and hybridizing signal types spoke in August we also have a couple more talks coming up by Yuri, one of the key maintainers in Yeager presenting in October, and then Jonah coval who is an expert on logs presenting so again we hope that this will actually happen and also pulling in and answering many of the end user questions because we do tend to get, you know, a good mix of vendors, as well as end users in the tag for observability. So overall lots of activity but we will be actually doing the update and then meeting at the ad cubicle in coming up in three weeks. And we also hope to have a good agenda and plan for some of the projects and initiatives that we intend to carry out next year. So, exciting times. Again, we continue to see more in engagement but would love to see more, even more going from there. And that's about it. That's I think all I had to highlight. And any questions. I do have a question so I was very happy to update all our hotel libraries. It from it city updated first and then humans updated. It took a little bit of time to get it right because there are so many libraries, and the version numbers are like all over the place. But we were able to pull that off so thanks for that. I think it's getting better. So we had to, you know, go back and forth between older libraries and newer libraries and there were some issues there but overall, good, we were able to do that. So the other question I had was, there was some chatter on the tag of servility around open metrics. Did that get resolved. Yes. Actually, so one of the things that I would like to call out an open metrics is very integral in the discussion around interop providing interoperability as you know, in the protocol between Prometheus and otlp. Right, which is the open telemetry protocol so open metrics has been very integral to that whole process. And in fact, Otel, you know, has supported open metrics first in terms of the existing standard and Prometheus as a project has also been working towards you addressing some of the implementation differences that they have with open metrics. So that is something we'll continue to work on but you know open metrics obviously goes without saying is an integral part of supporting a metrics protocol on Otel. And there is some discussion around that as I said you know there and maybe Richard you can also provide some details from the Prometheus project. And I think that is what has worked, which is ongoing and open metrics of course is core there from the Prometheus side the main thing is high resolution histograms or native histograms depending on which name you want to call them with. And that's basically the interface towards towards open telemetry to keep both the Prometheus high resolution histograms and the open telemetry ones in sync. So that's also going to be the next major release of open metrics course. It's going to be breaking along a few axes. Yeah, like that's coming to the T blah, blah, blah, blah, that's going to be breaking and that's, that's the mechanism of how to how to keep both Prometheus and open telemetry in sync. So that is still an ongoing open area, but both the projects as well as the metrics, everybody's working together towards ensuring that. Yeah, sounds good. Thank you. Any other questions attempts to your point about the installation and the, the versioning differences if you will. We'll take a look at that on the hotel side because I think you know, again our objective is to continue to reduce complexity and you know, ensure that there is clear dependency association with versioning consistent. We'll send you some notes offline. Okay, awesome. Thank you. Any other questions. Just a question related to this is like open telemetry is compared compatible with open metrics or they have different formats or. It is fully compatible. There is an interoperability work group on hotel which has been working closely that Richard and other open metrics, you know contributors, as well as with Prometheus. So at this point, the there is a set of compliance tests that you know are available from open metrics and that's something that we actually run through and make sure is is compatible. You know, the metrics is just a choice of metrics, but you can use other metrics with open. It's the protocol, the data definition, right so and then you can actually use Prometheus interoperably with open telemetry because the birth use open metrics as the baseline. Got it. Thanks. You know, when when to use promises when to use open telemetry or the scenario. I think there are many overlapping similar scenarios and that's an area that perhaps we can actually pick up and make more documentation available on, but there are use cases which are overlapping. There are also use cases which are, you know, very much in use in the Prometheus community, but are starting to get used on hotel also. So Kathy again, thanks for kind of raising that but I think that that's an area which would help end users in general kind of be able to have more understanding of where Prometheus is optimized and hotel, maybe easier to use. Yeah, that'd be great. You know, if we can have a document identify the overlapping functionality and also the difference. Different. Right. In which case to use which that's worth a user. Totally, totally. Thank you for the suggestion. All right. In the interest of time. I'm going to move us on in here. Thanks. Thanks. All good. All good. Tag network come on in. Hello, updates from tag network. We have not had a full set of meetings since last we spoke, we have had, we do have a few updates though. One is that Istio as a project has been accepted into incubation. And then we've have an upcoming presentation. So speaking of Istio, there's an upcoming presentation from a project called slime. It's a project that enhances Istio based service measures or enhances Istio deployments with additional management intelligence. And there are a few compelling examples of, of how to do that. So service mesh management. And then in the working. And so they're, I think they're filed for slime is proposed for sandbox and is asking for a time to present. And so that should be very shortly. So speaking of presentations this Thursday is our tag network meeting. By the way, just a public service announcements for the hundreds of people that attend tag network meeting. We switched it from we've had a bump in cadence from the second and fourth Thursdays of the month to the first and the third. The Kubernetes network had recently rescheduled reshuffled some of their meetings that turned out we were overlapping and so, given the two highly related topics we decided to move around and so. So, first and third Thursdays for tag network. So this week is the first Thursday of October, and we'll have a project update from the project network service mesh NSM. The next update is the details that you can see here but a bit of maybe even live demonstration of how network service mesh is a mesh for up can be used as a mesh for other meshes. So network service mesh, going up to layer three, and then having other service meshes operate on top of that. So, if you're into that kind of thing, we'll see you on Thursday. So that's that's what we've got for today and questions from folks. A quick question. So, the trend of using not using side cars and relying on EBPF based things. You know, there was something from Istio I think there was something from linker did two days ago. So, you know, what's happening there. Yeah. Yeah, I would have, I'm hopeful for a bit of an uptick in the, the service mesh performance project, as it relates to one of the compelling characteristics of the of the use of EBPF is about performance. And that this is maybe this is too hand wavy but but is that, you know, like, like any system design there's some tradeoffs that happen between you maybe you're getting higher performance. A bit of the there's actually there's a great book on this subject written by but no it's free and it's really it's really short. It articulates the notion that you'll yeah yeah like hey if you got a proxy right you know side card right next to your app. You are your risk boundary or your your ability to secure that those transactions is really granular. So if your proxy or the thing that's controlling those transactions is Damon set base or is you know node based it's a little bit of a different model that some of the models that are coming out or maybe helping overcome that, helping bring that closer toward the side car. I guess what I'm trying to point out is like, it's not a it's it's a sure you users like in Istio's case need to make it, they do have to make a comparative choice. So what I'm trying to say is that. Yeah, you won't one doesn't they aren't. And so in that is cheese boy haven't really formulated my thoughts very well clearly and concisely is it like, it's still not like an apples to apples like like yeah they're gonna have to make a choice or they're going to compare between the two modes and then figure out if one has all the functions that they want and they want to trade it off for whether it was performance or a different use case. And it's kind of disappointed to me personally that like they're going to their position as such, because, because I'd rather they were positioning, just as me personally speaking that I'd rather they were positioned in a more complimentary. You know, you get the best of both. Also go read the book. Yeah. So it's a project on that that Poxel is the epf thing. If you have doing the service mesh is a project for that. I think if I, if I meant if I got the question right. So Cillium is one of the more prominent, you know, service meshes that takes that epf based approach. And in there was a relatively recent release from them and it gets the 1.2 version of Cillium that announces sort of not just Cillium the project but service mesh as a capability. And then, yeah, to dims point to one of the other larger announcements more recently has been Istio ambit mesh, which is a, you know, an alternative deployment model for Istio itself. Okay, got it. Thank you. Yeah, I remember. Okay, thank you. Thank you. Thank you. There's no other questions. That contributor strategy. Come on in. I believe you are our last one today. Hi. Oh, well, hello, everyone. I'm Catherine, the new tag contributor strategy co-chair. So just wanted to say first I really appreciate the trust that dawn and everyone else have placed in me so I'm really excited to be here and thank you. Okay, so last time dawn mentioned that we were working on a survey with the CNCF. And basically the goal is to understand contributor friction points. The survey is open. We have 73 respondents so far. That is not a lot. And we need your help. I probably don't need to explain why this is important. I think everyone on this call gets it so please, please, please help us get the word out. I mentioned it during meetings. If you have any talks, share on social media, maybe there's a company newsletter, it would make sense to kind of add like a little call to action. Or any other ideas that you may have. The CNCF wants to announce the results during KubeCon so there is not a lot of time so we really need to mobilize people here ideally quickly. We have a KubeCon kiosk and the project pavilion so we're really excited about that. Our goal is to raise awareness. So we'll be showcasing the different resources we have to help projects project owners how we can help. We created this fun tag heroine, which was donated by the very talented illustrators one hoe. And you can help too. So if you're at KubeCon swing by the kiosk get your stick it on your laptop help us raise awareness so people know about the tag. Moving on to mentoring. So we expect to complete 110 mentee projects across the CNCF that is Linux Foundation and Google Summer of Coat. The goal was 100 so that's amazing right so over achieving here. We have 27 mentees we have completed the Linux Foundation project so far. We do want to do more outreach. So if anyone is interested in helping coordinate that please please reach out via Slack or join the mentoring meeting. And we can coordinate. Also, very excited about that we are starting our New Zealand indigenous recruitment program. That is a experiment where we're trying to reach people outside of traditional contributor targets. In this case targeting the Maori talent. So it is an awesome initiative. And hopefully this will become a blueprint for the future to reach out to other communities as well. So as I said, it's been mainly the tag has been mainly involved in direct project assistance, helping the operator framework draft a new governance, as well as helping K native and Istio run elections. So that's basically it but a reminder as always. As you're reaching out to projects regarding diligence or annual reports, please encourage them to get in touch. There's lots of ways the tag can help projects. Yeah, I think that's it. Is there any questions. Thank you, congratulations, and I wasn't sure if you would make it here but you did. Thank you. We left some notes on the chat on like how we can spread the word on the contributor survey. So let's do a few things there and see if you can bump it up. So let's do these things this week and then see the response next week. If you are still not getting enough responses then we can like, you know, just hit us up on hash to see and we can figure out like we can be doing stuff. I'm also going to reset the expectations like 73 is actually really good for most of our surveys. So, like, I understand like the question also like that's still really good. I understood. Yes. So, yeah, maintenance main list and things like that. So, let's do more. You know, I'm sure we can do better. Yeah. All right, anything else for taking tribute strategy. Okay, here are nothing. Quick update on projects applying the move levels. Any updates from the folks on the call. Okay, hearing hearing nothing like people rising up to be able to talk about projects moving levels. We have actually a few minutes for questions. And I know that there were some questions running around out in the wild so I have question for Catherine on the tech contributor strategy. So how's the contributor board. That's the name. I'm not sure whether that name may change the going. Yeah. Yeah, I don't think we have a name right now still. So I think. I don't know what the latest is I know that. Oh yeah now I forgot. Alexander was kind of taking them. Yeah, Josh are you. I think. I'm on the. So, the Alexander still planning for that part of the idea is that we actually want to make use of the data in the survey to look at what's going to be effective and helpful for the projects. I, as I said in the contributor strategy thing. We actually tried doing something like this in Kubernetes and it was not successful. So we really want to take a different and well considered approach rather than just throwing something out there. Because otherwise it'll end up with a repeat of the Kubernetes experience where we have a board up but there are no opportunities listed. And as a result, it isn't really useful to anybody so the so we're not rushing into this. And either Josh's head internet connection issues or I am having issues. Okay, all right. Nope, that's completely fine. Yeah, what did what I think I heard right of all of that was working on being able to get better data from the survey to be able to kind of help track and scope that more correctly. So, yeah, but definitely something that we're working on Kathy. And we do believe it's, it's important and useful. But yeah, as just said we want to learn from what happened in the past what didn't work and try yet to learn from that but yeah we do have people who are interested in working on it so I think it's going to happen. Okay, great, thank you. So, I did want to bring up something here. So, Nikita sent at being yesterday today I forget when Emily you remember that context right so it. So, right now we don't have all the information in one email file for example all the. Oh, you there you are Nikita why don't you speak to it please. Um, so this actually originated from the PR that was added, but requiring working groups to be part of tax. So it was at some context there were two things that came up with this issue so one was slightly tactical one was a little strategic so the tactical part was that we want to have a single source of truth for tax and working groups that also should be machine readable. We were discussing about this in Slack and the DOC channel just now. We also want to have some more information added to it about like who are the chairs and leads for these tags when were these leads added and so on. And we do something similar in Kubernetes already for six and working groups and I have maintained that so I decided to pick it up so I'm going to create a PR for it. So one more strategic aspect around this so the other question open question that came up was whether to see needs to approve working group creations or tags have the autonomy to just go and create it themselves. I think that was still open to the consensus with that first we're going to get a picture of what working groups exist which ones are active and so on. I think so I wanted to talk about that as well so I noticed there was some discussion and back and forth on it so have there been any progress and do we know the list of working groups. I do have a to do item to go talk to the serverless working group because I think that is the one that is left from the list that we had there. So, don't use that as a blocker for this, you know, we can, we can give them leniency or we can special cases for now. Okay. So let's just assume that all the working groups belong to a tag, and maybe you can propose a structure for the email file and then we can like debate about it on the PR itself. I think that's another thing that could be helpful but I'm not sure if we have like capacity to be able to do this when these things actually happened. But again, that might be a little bit of a stretch and be super helpful though. Yeah. Can't hear you. I think that should be possible so I'm trying to make it in the field. I will work with you to be able to make for that data is either like, you know, as good as we can do how's that. Sounds good. Anything else. All right. Dimms, I will leave it to you to close the meeting there. So anything we need to do for a cube con or before cube con or during cube con. I know the to see we have some stuff that we need to do there. Other than that. I just had a quick question. Is there typically a retrospective after a cube con that comes in from the tags, you know, because I would, if there isn't I'd like to suggest one. And the reason is that you know often we'll get a fair bit of feedback at cube con on various projects you know in each of the areas and that would be good to communicate back to the few. Absolutely. Let's find time. So actually our next tag update meeting is going to be November 1, and that is directly after cube con. I think given as you all are going to be at cube con, I'm perfectly happy to be able to have that meeting via how did keep con go details thoughts and that sort of thing. We'll be recovering from keep calling. We can, we can, we can cancel that meeting and let everybody take a nap. We've also got another opportunity on the 15th of November. I think the 15th would be ideal. All right. Happy to be able to track towards that. So this is likely, but we do have another meeting for the TOC coming up on the 18th. But again, that's the before cube con so. Awesome November 15 minutes. Thank you. That is completely fine. I'm happy to put it into the agendas. All right. Yeah, thanks. Thank you. Looking forward to seeing you. We are at time. Good to see you all. Bye. Bye everyone.