 Greetings. We'll get started at five after you can add your name and any agenda items to the meeting notes which I posted in the zoom chat. They're also in the CNCF. CNF working group Slack. Greetings. If you didn't see already their meeting notes and posting them to the zoom chat, we'll get started in a couple of minutes at five after you can add your name and any agenda items to the meeting notes. Tal, would you mind putting your note as a, I guess, an additional item? I think that is a list of the wish list items that Ian is suggesting. Thanks, Tal. If you don't have any, if you don't have access to the Google Doc, it is open, but if you can't reach it because of firewalls or whatever, you can post your name and any topic that you'd like to discuss in the zoom chat or in Slack and add that or just speak it out loud. All right, let's five after. Hey, Ian. So you joined any walking topics before we get started, you can add them to the notes which are posted in Slack and in the zoom chat or say them out loud or add them to the zoom chat if you don't have access to the Google Doc. All right. So the first item here is you're saying it's this use case wish list. I'll give you the mic. Okay. Yeah, so the reason I put this up is in part because we've been doing a lot of admin and I thought it would be useful to get to the point of what we're actually supposed to be doing which is use cases turning into best practices by probably a few design documents. I thought one way of getting is moving on that was basically to put a wish list up so that anyone who wanted to attack any of the problems had a place to start. If they had five minutes and they wanted to have a go at something and had no, no imagination. So I'm not remotely suggesting these are all of them. They're just really the first ones that came to mind. Anyone who has any thoughts on it who obviously I'm not going to say no would would like to take any of them on or would like to add any more they think are worth mentioning to it then. Now, now's your chance and I will find a better home than in the meeting minutes for it. Stony silence that's that's not promising any any immediate thoughts on what I put there or anything else to say. The point of your face, the point of the wish list is to kind of jumpstart more use cases, or is this. What was the point. That's precisely I'm seeing use case and I'm, I'm seeing use case and I'm thinking of, okay, a problem that, let's say service provider has in a real world or something. And then I see install a CNF. And I guess that's a problem to solve for them. If that's, if that's how you're going with this been okay. I mean, it's actually anybody's problem will do just fine. I will take problems for developers. I'll take problems for anybody. But I mean, basically, if we're going to produce CNF that do people some good, then they need to be installed. And if they need to be installed, then there needs to be some best practices that make them installable. And that's going to be confusing because I think it's hard to say what a best practice is when people haven't had too much experience of this. But on the other hand, if we work through the problem but saying, well, this is precisely what, you know, we're going to want to do. I'm going to receive. I'm going to have a development team, whether it's mine or a vendors, I'm going to receive a CNF in some form. I'm going to want to spread it liberally around my network. I'm going to want to run it on clouds, which is obviously the starting of a CNF, which is the next phase. Then what's going to make that easy. And what isn't going to make that easy is that every single CNF comes with 10 pages of instructions and there is no similarity from one to the next. So best practices here, I think would basically say, if you deliver about your CNF in this way, then that CNF is easier to work with because everybody recognizes what to do with it. Okay, so for some of these that we're saying here, it seems like all of the use cases need to solve these problems. So install CNF, start how the CNF deal with the life cycle is in. So you're kind of saying that the use case should address. Well, it would be nice if the use case said these are issues we also want or put a high priority for them to be solved in the use case. Yeah, so some of these are use cases so we're describing what somebody wants to do. And I would expect one use case per rather than a use case that describes all of them. And then beyond that obviously what we're actually trying to deliver is best practices so a best practice is going to be better if it takes these use cases into account maybe attacks one of them specifically and doesn't really touch any of the other in which case we've only got to measure it against one. Maybe it does affect more than one in which case when you're putting a best practice together you'd want to discuss how it relates to use case X and use case Y. But the reason we've got use cases is so that we can say why a best practice is truly best. It's better than the alternatives. Yeah, I'm looking at the sources so for BGP it seems like when they're just someone must be describing their BGP problem type thing. It seems like interoperability would be a quality they would want or or not want. Maybe they don't care. But if they do want it, the way that they install the CNF is important. They don't want it in such a way to where it doesn't work in someone else's platform or so on and so forth. And then so these, I think I get what you're doing and it doesn't need to be addressed. I just kind of back and forth on if these are individual use cases or not. I don't care as long as they're addressed then they need to be addressed. So how we do it, I don't know. I think the main point is to just get the conversation started. So if someone already has a problem and they want to put it forward as a use case, then they can do that. If they don't know where to get started, they can come and look at the wish list. And then maybe they read it and go this doesn't say enough. Maybe it should say this and they add to it, or they create a new one. It's, it's to help get the conversation started and get people going on. Eventually creating full use case. So I think we may have you and you said, let's put it somewhere. Outside of the notes, the discussion board could be a first start before we have anything else like a document. I don't know if we need this one or if we need a new one. There is one that discusses use cases and user stories and that wouldn't be a terrible place to sort of stick these things in. But if we've got no arguments on any of them, then it would be better if we basically had a checklist of some variety, whether that's a Trello board or something else it doesn't really matter so that we can actually tell how we're progressing on these things but yes, yeah, I mean, there is that. Suggestion maybe we take a look and we can do this afterwards, but we could probably create a board inside of GitHub for projects and you can do. You can look at that. Okay. I like this. Yeah, I'd like to start the argument going. I think some of us might have a different idea of what a use case is. Please do not look to me like what I would call a use case. The use case is a more specific application so mobile UPF sounds more like it I think. I think the list you started to create here. This is an opinionated breakdown of of the use case this is in a way a step ahead even ideas for example, installing a CNF versus starting it already assume a very specific life cycle that you know has to be examined per use case and to see if it's even most appropriate for it. You know, what does install exactly mean we often use words like onboarding. Some aspects of the CNF might be have to be pre installed. Starting. I'm not always exactly sure how different that might be from installing sometimes. I want to be clear why I separated those two out because I think that one's quite straightforward. If I want to upgrade a CNF in service, which I think is desirable for everybody. Then there is a big distinction between getting software out there so that upgrade can take place and the upgrade itself. So that's why I separated the two. I understand the rationale. Generally, I feel like these are. I'm tempted to call these things aspects aspects of all use cases all use cases would have to have some of this assuming even that all use cases are really divided into CNS right this is an issue maybe with even the name of this particular work group right we're assuming that all network services are decomposed to network functions that can be recomposed together in some way it's to me this is jumping putting jumping a little bit too far ahead already I I guess I prefer to start with use cases that have to do with what telcos call use cases that is actually use cases another word in telco I think for application or application type. Yeah, and it's why from the outset I've been talking about use cases and user stories I would agree. The case sounds a little more specifically, I am trying to do a certain networking thing, but a user story is telling the story of a user trying to use one of these applications and these are stories that a user has that are indisputably necessary to actually get to the point that my CNF is on the network and working and doing useful things for me. Maybe let me chime in and discussion book is speaking. If you look current definition of the of the use case in the template and and a few examples. It is actually none of what was discussed it's not the application it's not also a process oriented it's a description of a demand. Let's say or of the particular situation, the realistic situation which brings to the surface that the problems or the demands or the challenges we might have when we want to run the network functions in a cloud native environment. So I would not look at and now try to artificial or not artificially but try to force them they need to come from the users, or from the from the stakeholders that are facing certain limitations certain problems and describing their, their challenges in the way of description of the use case should give us as an input, something to work with to put it black and white if nobody's coming up with I have this situation and I have these challenges, then we should not address it, even. Now I understand the yarn, trying to stimulate a bit more work on the use cases so that we get these contexts and the situations. There are more transparent so that we can work with them. So I would probably prefer to stick to use cases as a sources of the real life scenarios in which operators or developers are coming and seeing some obstacles. Okay, well, then to take that. Start example, then when you start CNF today, how does that work. Yeah, this is something. Let's say I could. I could make an attempt to describe, actually, like we are onboarding couple of CNS or prospective CNS, I call them. They indeed come with the in the two flavors one flavor is. I deliver you like like a CNF developer vendor I deliver you entire stack from bottom up. And then it happens by some magic. Not by some magic but by some deployment ways and configuration ways that vendor put together entire stacking, including Kubernetes underneath and so on. But if it is onboarding on on a, let's say third party cloud or on a on a let's say operator managed environment, it comes indeed with the 10 or 15 on three pages, 20 pages of instructions. And it is mostly done. It mostly boils down to, you know, getting the health charts getting the artifacts in the right places, editing the values in those health charts, trying repairing. It's a bit of artisan manual process at them or not fully manual but a lot of manual work involved. And then when it's deployed. I think that that's a good question so installing and starting it from what I see is when it's installed it start itself, it checks the readiness liveliness and then it either is in reconciliation loop, waiting for other components to happen or is simply failing or So there is not, not this thing like starting a CNF. Well, all right, to draw a line between those two then installing clearly involves to me getting into a registry somewhere right you need your health charts in a registry you need to. Okay, yeah. This is this is actually the most of work if I if I'm talking now I could think of describing this in a use case format and saying this is how we what we what we see and face today and these are maybe some some challenges. You're right so it's the first step is really understanding what the application is. These applications are in most of the case your CNF are not open source project with the projects with a comprehensive read me files with a. Let's say documentation that is end user friendly or not end user but operator friendly. So they are mostly done. It's name of my daughter sorry here. She used actually. I see who is taking the notes. So it's book actually sorry. I need to to change my, my name. I forgot that my daughter was having a school on my computer. Sounds good. Yeah, so you have a right name. So where was I the applications are not are mostly intended for the for the service professional service people off that vendor who developed application and not for the direct usage by by the the operator. So this is involving a lot of interactive verbal discussions in a number of of online sessions in which we are understanding okay why do you have these artifacts like that. Where are the containers how you get them into registry where are the hem charts are the hem charts with the umbrella or not with umbrella. How do you deal with the CRDs in those hem charts when the hem chart fails. All those kinds of things are part of what I would not call install we refer to it as a onboarding, like to make CNF work. First time, like, starting up and saying hey now it's, I'm ready to be configured or to accept some traffic. So this is what we refer to onboarding and then starting is simply like maybe deployment process and from that on it's managed by by means of how you manage the normal Kubernetes application. Well, I've already now kind of improvising and making making a sort of use case verbally. There's some interesting bits that are coming out there right everybody I've ever spoken to on this automatically jumps to we started by running a home chart, which is interesting. So, at least today that is best practice. And I don't see a reason why that would necessarily change we can write it down as well. I don't see a way you can start things in Kubernetes but it does seem to be commonly assumed that when you get a CNF it will come with a home chart that you run to get it going. Yeah, I mean, in our case it's a bit different and this is where we are debating with some of the CNF providers. And started by using Helm installed because we follow the GitOps process so we started by committing its definition in Git and then wait until it gets started in the reconciliation loop. And this is what most of the of the this could be also one of the use cases actually we tend to see the pattern. Most of those functions as I saw today it's not, let's say wide range of them. I'm speaking on an example of three or four cannot name them now by name of vendor and and type because they're under NDA but most of them are really made for the imperative. Like you sit on the command line on some jump host and you are typing Helm install this and Helm install that and then looking what happened and then wait until one part is up and then you do the next part, and you follow these 20 pages documents, which are, in most of the cases written extra or on purpose for that particular installation, it's not like very general documentation, because I guess most of them are not yet in a in a shape and in a form to be like widely available when you get to, I don't know, office 365 you get install you get some install guide you click and then you go through it so they are not made yet for for such consumption. Mostly made for a system integration which is on one side right to be so on other side something that could be. Let's say improved with some best practices. So if we could ask, for instance, for installation to take that as the sorry for starting rather to take that as the example. Then there's two things and I've thrown in there that that running multiple since CNF and a single common platform is definitely user story or best practice is a little hard to say but but it's a common assumption. I think it's worth noting because it's certainly not what we find in in today's world, but the other part of this then I think it's undeniably a best practice that there is a single thing you do to make a CNF start. And that helps is interesting because that one strikes me as not necessarily a part of the CNF itself but a part of the way that you put the CNF to work in the sense that, and I'm going to borrow an O run term here because it lets me escape the legacy of Etsy and we had a VNF manager. And it did a lot more for CNF than you're ever going to need to do for Kubernetes in O run you have a thing called a DMS. And I think it's a deployment management system. It's not so much the detail of what they think DNS DMS does that's important and I don't know that it's explicitly or fully defined. In order to start a CNF then yes you probably do need a little bit of external help to actually kick it in the right direction to begin the process. And so it's reasonable to assume that there is some external component that does the general, you know, kicks it in the way that it expects to be kicked. So we have a pattern for what that is as you say, install documents and I know for well that Cisco is no better at this than anybody else there's no pattern for this there's no common approach for doing this everybody would do it differently because, you know, there's no shiny example that we can take and follow. Best practice. Yeah, precisely that. I have a nasty feeling that we're going to have to write some very basic form of CNF to just see how this could work and run some experiments and take that as feedback for our best practices. And I'm not looking forward to that because no one likes writing best CNS that they can't sell. So it's going to be a little bit of fight to actually accomplish that but on the other hand if we want to work out what is best then we're going to have to find out what is better and what is worse. And I think there might be some experimentation involved. So I have a few things out here. I'll just a second, we had a question added in here. I don't know if you saw this in. Will these use cases cover scenarios on how a CNF can be deployed orchestrated with own app and other LF projects. I mean, as far as I can tell, service providers don't 100% use own app everywhere. I mean, some do some don't. So the question is, what makes it amenable to whatever they might choose to do. But on the other hand, you know, own app is relatively logical in what it wants to do it's not actually asking terribly much so whatever we do should yes indeed work with own app so the question here another way of approaching it is what does own app want you to do what makes things work with own app. Could somebody explain what own app is. It's a higher level orchestrator for networking in general. Okay. So we have these discussions and it is a question. How do you transition from the VNF into into CNF world, and also how do you make how do you bridge over the period of coexistence of many different shapes of the network functions. There will be VNFs still for for the number of years or even longer there will be there even in a real scenarios there even PNFs physical network functions. So how we reason about that is actually an higher level orchestration is needed and we have also one type of orchestration. It is needed to connect and to manage this. How to say service training, like when you have a, for example, service consisting of the of the CNF and VNF and PNF. What is this higher order orchestrator that understands the telco network setup and they can wire those three things or five things together so that they can provide the end to end service. So that we struggled and then we are still in these discussions like, okay, but this own up or or mano or whatever you use it. I mean it's one form of mano if I if I'm not mistaken. You know, how do you control the pod failover the scaling of the of the replica set or these kind of things and then we have to explain to people it's not anymore the role of this type of software so you need to abstract it either on a higher level and see how it fits. So I what I'm pushing internally is really keeping that for a CNF on the level of the service training orchestrator when it can talk to net conf of the particular network function. And that's it. Not to deal with the deployment and redeployment of that function and and the stuff because it should be in our opinion handle this in a Kubernetes. That's what in saying though, for this problem. To me, this looks like more along user stories and I volunteered to take with your list here and put them in what you put called gherkin so given when then so given on an operator. When I have you can fill in the, you know, like I when I have a BGV BGV problem or when I want to probably be I need to be able to call this, you know, making it very simple, so we can address these very low level steps that are kind of orthogonal to describing another maybe a higher level demand that you would get with a use case where you can have scenarios and things like that. And then we can solve, we can address both sides and Ian's wanting to address some of these basic steps that as a someone in the world world, how they go about it's fun to see enough that that handled very nicely with the user story. As in a user story can be like two lines or one line so we can solve this very quickly to handle what he is doing. We can put a document out there markdown with what people are saying at these very lower simplistic levels or lower levels and and everybody can be happy because you know people can see it know that it's captured. And those are separate than say quality so interoperability or some other things which we were kind of mixing those qualities in with steps so and then all of that being demand so Yeah, I would add that we talk about the two things we promised ourselves will write a user stories use cases requirements and best practices, which is arguably implementation. And normally you would find a set of design in the middle so I think what's going to happen here is that we'll write up some user stories and then somebody will have to propose a design for some of these things. I would argue that, for instance, the requirements of ENO to take towels, you know, baby is it is a consequence of a design that hasn't necessarily been made completely clear. You know, it arguably solves use cases because if you design your system in a certain way the use case is all basically get sold by the implementation which is ENO to take one example. But to Vox point, just a moment ago. You know we have things like service training how are these CNFs working with each other how do they know where to talk to each other and so on with things like mixing and matching PNF which absolutely not going away I don't get very far without top of rack switch it's a PNF and CNFs. I think our problem is probably a problem of Lego, which is, it doesn't matter what color and shape my brick is, what matters is that it's got the right novels on it so that it connects with other bricks. And to my mind that's where we should find ourselves ending if we're describing specifically CNFs. We might choose to go further out and describe what the manual stack looks like and if we consider that to be a best practice that basically makes CNFs work, but if we work out what CNF looks like from the outside, how you relate to it how you wire it to other things. Then we should be able to use it with VNFs and PNFs without getting too much in detail of how those VNFs and PNFs are being looked after. I have a question here. So are you suggesting that the design we should propose for the CNF means are you suggesting that there should be some kind of a standard interfaces or the APIs for a given CNF which using which it can be connected or talk to others. I think that would be my take, honestly, if you're a, again, we had our audiences, but if you're not the developer of the CNF, if you're not interested in making it beautifully cloud native to make it more easy to develop, more agile. If you're actually a consumer of a CNF, then the thing that matters is not, you know, what language they chose and how many containers they're running. It's things like how does it export its logs, how do I wire its network interfaces to other network interfaces in other CNFs or other devices, this sort of thing. It's very much looking at it from the outside and not asking what the ingredients are, but making sure that the outside is the shape you think it should be. And we sometimes forget that when we're designing things, it's like we want to open the box and see what's inside, see what the workings are, look at those springs, they're all very shiny. But in actual fact, the outside shape is probably the more important thing to us here because that's what makes it usable. I'd like to suggest something that I hope will be constructive here. I think what we need as part of the description of these use cases and I agree that using a user case story is a good idea, but I would underscore specifically what the assumptions are. There could actually be different assumptions for each of these and best practices address those you know best practices don't come in a vacuum right you, you might already have a platform and environment with certain processes within your telco that you know that's what you work with so somebody saying well you're doing it wrong and this way is better. Well, that might be great on paper but you still have to work with what you have so, for example, even the trivial case apparently trivial case of installing a CNF which I think is nothing close to trivial. Assume you already have an inventory management system right. You might have to onboard it in a certain way with certain descriptors you might already be working with an orchestrator which might not be your choice you know if it's, say it's own app right and own app has its own issues and Etsy Mano as well and that they're still trying to understand what to do with CNF in first place. And my hope is that from our group we can give recommendations that can help them move forward in some ways. But in any case we don't always get to choose these environments and tool chains and middleware that that we have to work with so. So I think it's very important to put those assumptions right thinking about oh it could be a home chart, or a get ups or for some other kind of inventory management system and the processes. The business workflows the operational workflows that get you to the case where you have a CNF running right, which might be part of not just that CNF and isolation but part of the general network service that you're deploying including site management and all these other things so. So I think all of these can work for me if they have these assumptions listed with them otherwise. Yeah. One thing with the Lissy assumptions requirement. I was going to say that given when then standard will work because when you write it down and then you see 17 assumptions in the given portion of the user story. And that it starts to look like oh this is not something that will be a best practices is an edge case. And but you have it written you're not going to know until you see this thing right now. And so is the something darn that in user story, when you write it out. Oh, I would say. Yeah, let's bring this back to the topic what we had here was a request from Ian to try to kickstart adding user stories or use cases either one. This is to build a list so that people can get started. And then everything else we are we have already started addressing so tell you you've brought up multiple times that we don't want to have assumptions you want to get down to the base level and hold everybody accountable. These are inside of the requirements. And if your use case does not cover these things. Then it can't be referenced from a best practice and a best practice will not be adopted unless it has a working group use case that goes through all of the different items, including stuff like involve system so maybe you're already using them. But right now, all we're talking about is how to get started with more use cases and user stories. We want to start adding them so if whether you have a simple one, or I'll say a more focused. This could be from your point of view tout a component level. This onboarding might be part of something larger, but we don't want to block anyone if someone wants to focus on onboarding, let them do it. If someone wants to focus on something larger great whatever you're wanting to contribute to that's the point that Ian was trying to get started was let's get contributors for more use cases and user stories and I think Watson it is great to start creating some set of user stories that provide the context what what we don't have as a template for user stories, but you're talking about something that would address stuff. But get, we want to just get started and not block anyone. Yeah, don't hold out for that template template will be best for us if we write a few user stories and work out what is helping to make them understandable. I agree. So this might be for the user stories, the use cases. Wish list Adam here, Adam somewhere Watson if you want to create a first set of user stories based on stuff that sounds great we just want to get started is the main point. Everybody's been talking about it and Ian was trying to help get things started by let's at least create a list and not block people from contributing. It's actually to start meaningfully addressing the or creating a best practices, we need a consensus or not a consensus but we need a bit more context. And this context is going to be built with a couple of use cases that cover. A decent surface for a for a beginning we don't need to to paint entire picture or write entire book of every edge cases and so on but at least to have a couple of and to say is this what we are also sharing as a real situation as a, let's say set of pain points and let us in a follow up on that star describing the best practice or debating the best practices if you will. So what I can volunteer is really continuing what I did with the life cycle and maybe talking a little bit on onboarding to describe what we are facing written somebody can jump in and maybe correct it from another angle or complemented. Your idea of complimenting book. So this you added this one. It seems like in response to Ian talking about install. It's okay if we have multiple use cases covering the same area. Yeah, someone may come up with something based on what someone else talked about and that's okay use cases are not saying this is the one and only. We may come up with multiple best practices we may come up with multiple best practices and then you have different options and paths. The, do we want to move on and give some time to talk about some of these other items. I think a small 10 gentle Ian you mentioned the fact that we might need to write CNS and actually create something that might be difficult so I'll just mentioned on my team is working right now on creating orm CNS. Well they'll be mock CNS the point is that we were trying to build something that we can actually orchestrate and compose the CNS themselves don't do anything. And the intent is that they'll be fully configurable using the three gpp gang models that are referenced by the orm project. So, maybe that can help. And we're definitely using it as a place where we can play around with what we think the best practices are so we for example preferred use Kubernetes operators as a way to to install and manage and do ongoing changes. In any case, obviously this is a red hat so we're going to be doing it open source and in the open and when we have something to show it might be useful for this work group to look at. But y'all have a lot of use cases and user stories, and it would be great if those could be maybe broken down enough to not have any, anything that would be, I guess proprietary similar to what Luke was trying to do when talking about onboarding. Y'all probably have a lot of use cases that would be applicable outside of red hats so that would be a good area. I'm not going to sign Oran here so it's designed to be open. Yeah. And I think we, I don't think we have to build a fake or a real ran architecture to necessarily come up with useful things. I'm not going to say that a router is a particularly useful thing to build because it isn't quite honestly, but a router that takes static routes is nevertheless doing a good proportion of what CNF would need to do if it's forwarding traffic they all basically have a fairly common set problems and a lot of them would be shown up by having one of those similarly a BGP speaker if I took go BGP and tried to make it into a CNF would show up a lot of the common problems that we would come up with. So it's possible that rather than again we get into some difficulty here because we all have jobs that we're paid to do and writing an open source BGP speaker is never going to be a part of that job for most of us at least. But on the other hand, if we can find things that are small digestible components that we can take somewhere. Just to say, well, this is representative of certain bits of what CNF is going to have to do, then we might find that it's going to work a lot faster than trying to get people to share what they're doing with their own CNF that they're producing, which to be clear is usually set in stone by the time that anyone's willing to discuss it because oh it's shipping now so we can't change it customers are using it that way so we can't change it. We need to compromise a little bit to find out how to get ahead of this. Otherwise, yeah, you know, we've already seen that you know different CNF vendors and again I'm not saying that we're we're blameless in this. They have their own patterns for doing this that may or not may not be good. But once you've released a product they're actually kind of hard to get anyone to admit that they need changing. Let's, let's go ahead and move on. If anyone has any. Any items to add as far as new user use cases or user stories, either one for right now add them to this discussion item where we already have some listed, and then we'll move towards whatever we're going to do as far as if we migrate them over to another event if we put them in the project board, but this one is here. Please start adding them. And then if there's anything that you like then just create a brand new discussion to focus specifically, or do a PR, if you're ready to go. One comment Taylor, if I just may regarding this writing the CNF. I think we would have enough CNF or CNF references to use in our discussions debates, developing best practices, so I would probably foresee it like not immediate think we need to do but when we have a comprehensive set of best practices, we could even invite all interested and say hey can you bring up the network function that would satisfy all these best practices or most of these best practices in a form of kind of competition or something to show. Okay, this is really cloud native or according to the best practices a function so I think we could create an intrinsic motivation after we publish the set of best practices and invite openly. To bring up something and then show off at the end. Sounds good. And I'm sure we can collaborate with some other groups that are have testing sessions about that. Do we want to talk about the 95. Do you want to go into this at all this use case. We had a PR to add it. So trying to move on to see if we can accomplish a few other things. I think walkers around this. Yeah, Jeffrey was requesting the edits on it, which I think I fulfilled I was not coming back to it since I was off last week. And then some days before. I remember that I was addressing most of the issues. And I'm honestly and other waiting for his feedback on the new text or if you go scroll down. I think there was a. It looks like there's several commit suggestions for Victor. Yeah, even I think I was. I was accepting some of those they were where they are all accepted. You'll have to click do you have the commit button. Let me let me check that I need to look into that one but other way, other way around if you go to the bottom. You'll see that one change requested in the changes requested in this pipeline run. So if you look at this. I think I did. Maybe those changes is just taking Jeffrey, maybe we can follow offline. Yeah, I'm going to just click this to let everyone recheck. And yeah, I'm happy to follow up with you and make sure that you have access to accept these, you should be able to see this button and click commit suggestion. Quickly open that issue. PR. And then have it. Let's see, so I'm going to move on to a few of the other items. Let's see. We are going to cancel the telecom user group May 3. It's conflict. It's conflicting with the cube con day one events. And the next telecom user group meeting will be June 7. I suppose that means we should also maybe cancel the scene of working group for the same day. And in May, but we can come back to that we're not here. I don't know if anyone I'll point out a couple of things. So if you didn't see we merged the move of the governance items into the new governance document markdown. So this was just migrating those. Ian, this is yours again, expanding on the best practice. I think we may have, yeah, we got a bunch of approvals so this is cleaning up this best practice document and making the language a little bit more consistent. I think you reordered. Yeah, I tried to. I tried to reorder it a little closer to the sequence of events. I've padded out each of the sections so that some clarity and what sections mean and then I just set to on the language so that we're actually, you know, when you read this in a list it looks a little bit more like talking about comparable things but yeah, nothing too exciting here. I'm mostly impressed that people were approving it without complaining about it. So I guess we're roughly in the area of consensus. I wasn't expecting that honestly so that's a nice bonus, but unless anyone's got any objections then I think we're about ready to the point that we could commit it. I think there were some objections with committing this mainly cleanup and then he added all of these descriptions so that when you're coming in here. There are of course no best practices listed yet. This are trying to show different categories. Yes. And bear in mind right again, the point about this is it's better than it was. It's not perfect. You are welcome to propose more edits on it. There's no limitation to that. Victor. Are you here. Yes, I'm here. Okay, probably to revise. Yeah, and to revise the changes. Yeah, probably the major difference between the previous change on this one is like I would just remove the 80 characters mutation. So, you know, you still modify a few things but Yeah, it's covering this. You've disabled it. I mean to click that. So you've disabled the 80 characters. I think I just went to the wrong one. You've disabled the character length requirement. And I also create like a make file for like, for new people just to run main instruction instead of trying to figure out the way to run the lender locally. So, yep. One other thing I found with that is because this is actually checked into the repo. When you push to your own branch before you make a pull request then it runs the tests on your branch for you. So you do get some feedback there as well it should get it should any problem should come up. You know, several times before we try and commit anything. Yeah. All right, we didn't tag enough people so I just tagged a month and maybe get another set of reviews and then we can get it merged this week. This one add values to the starter. The wording here. Let's go. I think we need to maybe tag a few more people. The first step was, or I guess the first iteration suggested was a simple list. And I believe this was based on something like Kubernetes community or. Are you on listening? I don't know if you're able to speak to the reference where this actually came from. This a simple list adding values into the charter related to mission. Well, this one I think could use some more responses. There's a lot of. Okay, I see a chat message. So there's, oh yeah, here's the references. So the tests go harbor tick the some different CNCF projects. There's been a lot of comments on this. I think we may need more folks tagged so we can get it. Very good. So the, the main comments in here about do we expand from a simple list and have longer explanations. And are there anything else that we want to cover. And this would be more of the, with the split of the charter and the governance. The longer term time tie in with bigger goals, mission statement and values for the whole group. So please take a look at that. And give some feedback. So PR process proof. I don't know if Bill is here. I've put in a discussion item. We're right on time. So just, I will need to drop it if you can take a look at this discussion about trying to make the whole process for full request be a lot faster and simpler for most items. So items would be able to move through very quickly. And then the items which are need more approval and more thought before we go add them would be the only ones that would have a different process or more involved process. Everything else would be part of the contributing guide. So how to get through. And there is a PR. So for this discussion so you can add comments to the PR or to the discussion either place. It's been some people that have already started giving feedback. And you can see how it fits into the charter and the, and the contributing guide. So charter and then the contributing. Yeah, so there are a couple of points here one is we were sort of debating about tech leads and what they do. And my proposal is that we basically work out a reviewing process where then we add tech leads to it to speed it up. So we put something together which basically just uses community members for the minute and then we start, you know, we can build a role for the tech leads we know what they're going to do, because it's clearly how we get things to go moving forward. Not building things in advance of knowing whether they will help or not. And the other one is that we don't need to get too complex just yet if we aren't ready to build, you know, best practice baselines that we're going to put out and saying here's our version one. Then we don't need to write that down yet let's learn a bit more and write it down when we're a bit more certain about what we want to do. So we don't have to over engineer this just yet. Well, take a look and give some feedback on this, and we will see you next week. Feel free to chat on slack online. Thank you. Bye bye. Yeah, bye.