 I hope everyone's got the link to the chat again, those who have joined. Right, okay, so let's crack on. So there's no new announcements that I'm aware of that need to be shared. The only update to this section is so I've moved, this had the main KubeCon as it in person only, which is not. It's just the Kolo events that are in person, so I've just updated that. And we've seen a shared a link in Slack, which I've put on here about marketing prospectuses for Kolo events, the KubeCon EU 23. There's a interest form if you want to fill that in. Find out how much it is to sponsor a Kolo event. Any other events that people are aware of that aren't listed here that are interested in this group. Can everyone see my screen? Thanks. Okay, let's have a look at the PRs then. Okay, so we'll review the PRs and the issues. So there aren't any open PRs at the moment. There are some open issues and I think there was some notes for two of them. For Victor and Taylor to start drafting something. I don't know if that's been completed since or if there's still, I don't expect this is for these two, isn't it? Yeah, yeah, I haven't started like the document yet, but that's the idea. I started like doing that, but I don't know if that's been completed. That's fine. This one, okay. Cool. Okay. And then this one I think was assigned to Taylor. Cool. Okay. The top one is. If you can go back to the PR. So they. There was a ticket that was open for a good while. And then there was a new one that was merged recently. This one's a new one on the CNF dev. The other one was a single category, but now it's pretty. Far out of sync. So we need to review and look at. The test categories from the test suite. And, and then looking at the best CNF. And then I think Robbie put together. At the start as just a, here's a idea for what we could do. So I think there should be more in sync, especially for being able to maintain them. And I think most of the contents available. To copy over. Into those areas. Like there was some stuff that was TBD. But there's a lot more over in the. On the test suite side. So I think. It's more of a. Like, yeah. Compatibility and solubility upgradability is a. So somewhat collapsed category instead of having stuff split out. So. Microservices are normal reliability, resilience, availability. I think that one is. The same type of category, maybe just the naming was different. So. I should probably know this, but for some of these, for example, you know, it's fairly clear what the best practices. And, you know, what's being tested and therefore what's flagged as being not the best practice. The things like. Network latency or. I don't know. Increasing, decreasing capacity. About. Is there anywhere in the CNF test suite repo that describes what the. The thresholds that are being tested are. We can backport into the best practice. So I guess the answer is. The different. Descriptions and informations about why things are tested is available. And so the contents there, but it's, it's going to be in different places on the test suite side. So why it's tested. There's a. A document just for that in the test suite that's focused on the why. And then the what in the house. So all of that's kind of split out. Yeah. All right. Yeah, that makes sense though to reverse engineer this document to the. Best practices for CNF developers. And this is really just talking table of contents. That's what that tick was. It was related to another ticket. That was about adding one category to this whole thing. And that's been done. The resilience category was added at number 10. But the. Reworking of the table of contents is why there's a new ticket. And then I think beyond that would be probably. A lot of other tickets that need to happen. To break down the work on what you were talking about, which would be good. Take the different tests. And then, and then we're adding a minute's best practice. Now, what I would say is we start with the ones that. We have one published. There's. We need to publish the best practices. And then they can be, you know, brought into. That document that document's supposed to reference each of the best practices. So right now they, you know, the, the first one we had published was. Don't use root in your. As your. For your processes in your containers. Yeah. But we could go through and. I think it should be different tickets. We don't try to do it as one big ticket at all. Definitely. So they don't use root bits in. Yeah. So there's a different document preach of these. Right. And so you could have us a short little. Some. At least reference the narrow route in, within the category area of the dev doc. So if people are going through and they say, oh, I'm interested in security or whatever they're. They can click find it in the main doc and click through to the. Underneath. So that's like in section seven, which is a link through to the. Detail page. Yeah, each of those could have like a bullet points. Here's the best practices for these areas. Yeah. Sounds like a balloon. It's my door. It's really squeaky. Okay. Yeah, that makes sense. I've made a note about that just in the, in the issue. So the moment that's assigned to you and. Lucina. Is that just because you've authored it or are you planning to do it as well? I mean, if. You know, ideally we get some help that eventually we want it to reflect. It's, you know, the ideas to have all of these things tied together. We could definitely use help though review, you know, reviewing and saying, okay, can we. Is it okay to just match the categories? And if it is, then that'll. Make it a little bit easier. If it's not, then we're going to have to. We're going to have some type of reference where people come in and looking at the working group and say, how does this relate to the. The categories and the test suite and the certification, which is also there. And of course the other part is maintaining. So we've already, you know, fallen off some on this. But if they're in sync and they have the same categories, then any time there's an update in one side, then it can also be. Yeah, at least create a ticket to update on another side. Yeah, well, I was just sort of thinking about that whether we. In this page or some in the CNF test suite, we wanted to link back. So, you know, for example, check through user, we can have a link back to. The page. Then as a link to the detailed. Document the bell. We could cross link to test as well. So the, the working group docs have mainly been about. The. What and why. How things are done. How it's implemented or anything. Is it tested with. If we're going to do that, then we could link over like run time analysis. This has the section referencing Falco. But it doesn't. I don't think it links directly to. The no rooting containers tests over there. But we could do that would be a cross cross link on that. I think that would be useful just to kind of get a clear review on. The link between the working group best practices and the test suite tests. And then, and then we can over time probably more clearly. Delineate having the, the why. On in the working group and the how. In the test suite. I'm not having to overlap and repeat ourselves. The main thing is having enough people to, are we going to have people to maintain? Yeah. Then it's kind of been. As the tests were written, make sure that there's some right up in the. As the, as the why, but we could split things off if it makes sense. And there's. A collaboration and ownership. Better, which we want. We want better collaboration. So the, the, before we go into that, though, the, and that should be a new ticket, like add for this one, non-root. Add links to the test suite for the, the. The test that's checking for non-root. And I think there's. Maybe a couple of variations. So we'll need to figure that out. But if there's a ticket open on this one. We can add it just to this document. So a new ticket. And then the other was just. If we can get some feedback from folks on. The categories in the test suite. And if it's. If we can match them in the CNF working group. Table of contents. Because that's the, like the very, very first step. If that's good with everyone, then that'll be, we move forward on that ticket. I'll hold, I'll hold for a minute while you're doing this. So. So the table of contents being this one. For the one in the test suite. Update this one to match. So the question is. Can we match the categories. In the test suite in this document that's showing. Yeah. Yeah. So that's the, that's the issue you've created is. Can we make that table of contents match this structure that's in this document. Yeah. When mainly just the titles. Yeah. Yeah. Exactly. And then once we've done that. I'm then creating an issue to just for one example for. Linking the. The non-route test within the test suite. Back to the note non-route. Best practice within the CNF working group dogs. Yeah. Yeah. Can you on the test suite? Can you open a new document? Yeah. I think it's probably a couple of documents to look at. One is like list of tests. It may be under the, is it under the docs directory? Let's see. Test categories. Oh, there it is. So open that one. And then the other one was called. And there's a link in that. So you could go to the one, but there's rationale. So if you find the one. Called route and you'll see it, it goes to it. So these are more minimal. Okay. Test suite. So I'm not trying to duplicate entire. Focus document on a best practice. Within the suite because that was the idea is the working group would have those larger documents. Yeah. But the rationale has the short version and a link to more content for each of those. That non root link. Do you see that. In the title. This one. Yeah. Yeah. I think. You might go to the. Yeah. The list of tests. Is that what it is? Yeah. Yeah. Oh, it didn't work. Yeah. Maybe it's changed or something. Yeah, probably changed. Or disappeared. So that's where it should link to. Yeah. Yeah. And then. You know, that provides more info. There's usage link that link. That. Did the non rate go to the code? Just the title. Yes. Yeah. So we, I mean, you know, we don't have to focus on this, but that's. There was a question earlier about what. What are they. For that one test. Do we have the information on. The limits or whatever it was. And some of them are in the docs and they keep being adjusted. So we'll need to, you know, if it becomes a best practice. We'll need to decide like, is this something. That we're specifying. And for some of them, I anticipate that it may be a range. Or, you know, some type of guideline. Yeah. Here's what he's saying. And that's sort of thing may change. Like the startup time. As. As more applications move over and there's improvements and other things than it may reduce. You know, size of applications, what's reasonable. Other things. Yeah. We'll have to keep that in mind that. We're, we're writing living documents. We don't expect them to be set and stun for forever. Not for 18 months or a year. However long that they're realistic and we'll update them otherwise. Yeah. Anyway, I think he's fine to, to link to the code. If that's the best place to document it. That's still valid. Yeah. And so we can. I would probably say. Link to the list of tests. Rather than the code. Because we'll update the code. Links in this document anytime and. Yeah. Anytime that changes. In the code. So if a test. Is updated, modified. Sometimes replaced because it's refactored out and we get like a. A totally new version from someone upstream. And. Those will update, but from the scene of working group, to the list of tests, then that, that'll be fine. And then people can click through for more. Makes sense. Of course that one, I think didn't work for some reason. It's just the type of the headings being changed. Therefore the anchors changed as well. And on rate. And so not to the rationale. You know, keep that as it is as well. That makes sense. Yeah. Okay. Interesting. Doesn't get picked up by the lint checks. Different. Different. Okay. Okay. That's clear. I think. So. The only other issue we haven't discussed is this one. Are we expecting him to respond or. I don't know how active he is. Yeah, basically we were. I can respond from the end. I've. I think he's been taken away from a lot of this. He's just. The first response last week. To a totally different question. That Jeffery had. And I think he's probably not going to be available. So we will have to just take it on ourselves. Yeah. Should I remove him as an assignment just to. I think so. Reduce the number of emails and kits as well. Okay. So. Victor, do you reckon. If you're happy with that. Do you reckon we need a review from anyone else instead of being. Okay. Okay. Okay. Good. Okay. Thank you. That's good. Right. Any other business. Okay. I think. Is it next week that there is no call. Let me just double check. Yeah. I think next week. What's going on next week. I'm not sure. It's not in my calendar. It might just be me. No, it's on. I think. Let's see. Yeah, it's on. I will recent. Okay. Thank you. Yeah, I see what happened. It's you just replied. No. Yeah. I think I wasn't able to. Yeah. It's fine. Victor's leading next week. Okay. Okay. Anything for anyone else? Otherwise. I was right there. Thank you. Thank you. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye.