 Okay, I think we can probably get started. There's quite a few people on the call and People are joining late can just catch up afterwards So thanks everyone for joining. This is the CNF working group in case you got lost and stumbled into their own conference room We meet weekly Mondays at 1600 UTC And this is our first meeting for this year so before we jump into the Agenda items. Is there anything that anyone wants to add or likes it would like to see before we get started I do see that anonymous wombat is adding chaos experiments That's me. It's Taylor. Okay sure and There's nothing as I if nobody has anything else to add I guess we can Jump right into the agenda then So first on the agenda Is Vuck. I think he's on the call, right? Yes, I'm there. I'm prison. Okay So Your discussion item was about this discussion that you started about CNF candidates for assessment. Would you like to Like kick it off. Do you want me to open it for you? Would you like to share your screen? No, I didn't make much out of it. I Wanted originally to initiate the discussion as we are putting us in in position to make some best practices and then some Some rules for for evaluation of the Cloud native network functions. I told some of the developers of the network functions might candidate their own projects to actually also interact or Not only to define the best practices and the requirements, but also to to do that By having in in sight Couple of I'm not saying like long list of the application, but couple of very concrete ones That we can use as a basis for for aspiring on On these best practices, but really to do the concrete evaluations Of the of the concrete functions as we develop best practices and then it would serve us potentially to fine-tune To choose if some best practice is really Relevant and meaningful and some practices are not in that sense. So just to have a little bit concrete Basis for discussion because I felt that so far we have been fairly on a on a high level and then I thought it might be good to If somebody of the developers would candidate their network functions with a which they Consider maybe very much cloud native or even some that are having some issues with that so that we can run them through The best practices. I wanted to start this discussion in the in the forums, but obviously due to the holiday Seasons there was no much traction on it. Yeah, absolutely. Thanks. So is there Any One who's even there a senior vendor developer that would like to Volunteer one of their CNFs that we can actually have some kind of like world real world assessment about this or no some It also doesn't have to be immediately. You can also say I want to take time and reach out to some people I know See if they'd be interested You know so open question in the round here What do you think about that as as an element of our work here? You know, is there some opinion on that one? Maybe it's right Avenue to to go maybe it's not so I just want to throw it in the round Hello, this is Victor Morales. I just have a question regarding this. So the idea that you have is basically to list or to reference the the CNF from here to the projects or Because what I have seen is like at least in the CNF test best project. There is a couple of examples where we can you know user or Yeah, I think Taylor put it some information there so Anyway, probably I can put the same comments in the discussion to grab it there or But for now, is that what you have in mind like leads to reference those CNF from the repository. I don't know that Repository maybe I'm just looking now. Okay Yeah, that's it. I can I can take a look We'll need a bit Time but yeah, they there could be these What I see on the layer, maybe I just take a review if you can put the link Maybe that's what I meant. I was more on not more but I was in generally looking towards having well-defined And and let's say packaged productized CNF that somebody of the developers when those open source project has and then use it as a as a real life check for the For assessment. So essentially trying to do assessments according to the base practices generate Like there is one that Was sent about the operator view platform view the assessment sheet that's in the in the Google drive Using these these statements these criteria using the best practice criteria and then just checking but I look at this page and We'll review a couple of those and then provide the feedback if These are actually those that I meant would be useful Okay Maybe maybe some of just to add to that maybe some of More challenging functions for example taking 5g core data plane intensive function Or something like that to use to provide the borderline case because these are From the practice appearing as the most problematic or not problematic, but most challenging once to fit into Normal model I think that there's also We would probably want to go over more than one In this like we want to start with one, but there's there's different There's different models. There's different types of common threads that we're going to see here that that we may want to investigate and Check against that particular pattern. So for example You may have one that is very heavy around Around How how a pack of corn may work and and that those have certain assumptions and certain control plane assumptions that are that are made then you may have others that are that are Completely separate, but Don't don't have the same level of requirements on on the control plane that freezes up to To how do we build and manage it without having to bring in all of the And I don't want to use the word legacy but all of the assumptions that you that you would tend to have in in a pack of corn environment and that to see what the differences are like if you're bringing in a Firewall as a CNF then The control plane requirements are very different from something like like a packet core. So We so we should make sure that we over time and go over more over more types of environments to to see not only a Not only how are the same, but we're where do they differ as well while still focusing on on That kubernetes on being that kubernetes native style approach Looker you Were you only interested in open source projects? open source of products that are Also Not only necessarily there could be Also the the commercial ones because I think it's Probably prevailing model for those bigger functions But for that we would need the developers who would be ready and who would know the details of those and then can Answer the the questions can can check whether the patterns that we are defining are Sustainable for that function or Not and That could be a trigger for some discussions Why not and and what holds us from or hold that particular developer vendor from Adhering to these best practices. They were just really looking for How to get to the good discussions on the concrete points As we could start from the open source ones Probably going to be easier So on the open source side and we can probably map a lot of the Applications, but those may Those are likely to end up being one part of a product whenever the CNF is actually Deployed and sold as far as a production CNCNF network function so the list that I put in there that's from either if we're going to like the examples from CNF testbed the The list of examples on the test suite that first one that Bill it up and up where you go look at NSM examples. Those are all the smaller components and stuff For the most part Unless you look at a use case I mean if you if you look at a use case instead of a product then we could probably Take apart the different pieces and go. Oh, here's a single application like the v speed use case you're going to have the AAA and DHCP and a lot of other pieces that you have to have so those are part of it and then you have like the different gateways and those could be If if you thinking about a Kubernetes based deployment then ideally someone could You could have different vendors providing the different If desired you could you could get different pieces of that use case from different places. So you may actually have your Gateway at one end that's from someone and you don't care that it's not from the same vendor because it all works together But that would be going from like a use case and then breaking it down Otherwise, it would be nice to get some CNF Developers that are able to speak to it like you're saying if I Mean if you look saying we need to be able to have access to code more than having people available to answer questions and talk to us about Are we coming up with best practices? They're going to help them as developers whether that's a app developer or platform Developers or ops team Do we have the people that can give feedback on on the best practices that we're discussing? Correct And it's some later stage hopefully then Bring the artifacts in certain reference environment and also be able to to do the test to run the test against that if we Let's say progressed over that compliance Approach on the other side if you're looking What the results what these best practices could be used for and there was a discussion around the PR? Which was around the initial framework Yeah, I think that leads into our next discussion. Yeah, they're potentially but potentially I just wanted to reflect why that Interesting so if you have a good job down here, then many operators will take this list like Today for a security things around Kubernetes you go and take a CIS list and say, okay, this is what I want every Vendor supplier whatever to fulfill and then you put it in your RFQs. So ideally if you did a good job After some time and have a set of best practices many operators will take them and put them in the RFQs when they're choosing the Or RFPs when they're choosing the network functions Cloud native network functions and if you create something that is disqualifying or that is reducing Visibility for many network functions due to reasons that we didn't evaluate on a practical Concrete examples, then we might cause some Some some some challenges or some problems to those so that would be really Interesting to have a dialogue on that and then something We believe is a is a best practice and should be done a certain way Is not supported broadly then to understand why and then see, you know Is that then a best practice or not or is there actually advice how the limitations of the CNS could be Overcome so this is all a sense of Searching for a concrete examples and then concrete dialogue with the developers Yeah, absolutely. I think that kind of so if anybody has any Ideas of who wants to contribute to the discussion or candidate CNS, please feel free to add it to the discussion item Here in the repo and then that kind of leads into our next Item on the agenda is the kind of the initial framework so things once again Robbie for putting this together I know Vuck has you know, there's a couple open Things here, but has everybody had a time to look through this or does anybody feel like they need like more time to look through this Damn from Bell. I'd say a bit more time coming back from holidays Maybe next time Okay So I think we can probably leave it open one more week and try to get it merged by next week Is there anything that anybody wants to discuss? Specifically specifically right now I Comments need to be at this right. I'll have a look at that. I'm trying to make sure I this thing will come in a few days Okay, and Robbie is there anything you'd like to bring up right now about this PR that you created Please approve it I Think I'm hoping this PR will clear this initial framework. So ideally speaking this will be the Framework that we will base our contribution on so I encourage everybody to look at that and once approved I'm hoping to follow The scheme that proposed by this PR so make sure we do our work more efficiently afterwards I'm going to say what I've been saying before which is This limits our scope if we put it the way, you know and literally first time I've read it for apologies But it limits our scope if the first thing we say is It's a question of making sure that CNFs are compliant against best practices because the best practices have to have reasons behind them so there is a Bigger problem to solve before you can start saying CNF should be built this way I think Um, so actually I think if we jump down to The actually it's not here, but the the descriptions it actually Each of the like templates actually does have or does ask you to list the reasons Why each of them should be so so there's goals non-goals like the user stories The why so if you think something else should be included in here well No, I mean, that's fine But normally when I'm writing a document like that, then I'm saying here is my motivation Here is the goal that I'm looking for here is the thing I'm looking to accomplish And then I refer out to why that goal is a laudable one why it's the one that we should be aiming for So where do I refer out to? So just to just to clarify so we actually decoupled the best practices from the actual Document so what that really allows allow anybody to propose a best practice and as long as they can prove that There's enough data to backup why they think this is a best practice It it will go and this is the template that Bill is showing and if you feel there's any more information You would like to see for any best practice before it can be Validated and it's a promoted to be approved as a best practice We're gonna pay a certification on so this is something we can include in the template if you well Well, I'm not really I think I mean if if what we're doing here is best practices. That's perfectly acceptable I'm saying what do we consider authoritative references for For motivations so for instance to give an example If I assume that all my CNFs are going to run on motors, then I want someone to have made a an informed and reasoned choice in That he's documented for with their reasoning somewhere else So when I say well, I tested running on motors like this that and the other Then I've got a reason to be testing for that and a reason for the best practice to be acceptable Bad example, but I'm trying to get to that point I'd like to add one more thing to this is One of my you know one thing that makes me nervous is despite this whole everybody thinks they're agile now The service provider world likes to play at it, but like certain things just don't Conform well to being quote-unquote agile. So what happens? What is going to be our process if a best practice? six months from now Turns out to not be a best practice or this and that like how are we going to prevent like The road that Etsy went down where they wrote a bunch of arbitrary things down at the beginning And then it was like we are never ever ever changing these Especially kind of to Ian's point if we're saying that you should be building to these best practices and one of them is debunked like how do we keep developer trust when we say we need to like Go back on this or we need to modify like you might have to start changing You know x y or z part of your development if you want to keep following quote-unquote best practices So if this is a riction we're going to take I think that we definitely need to make sure we establish a set of principles and say like these are things we tend to look for in general regardless of technologies such as the system should be able to Withstand a a container or pod dying without losing service as a without losing the Significant service or degradation or we think we can come up with other general high-level things But when it comes down to low-level implementation details, we have to be a little bit careful here to give you a really good example Then and not in the not as much in the Container space, but let's say you're talking about like best practices for maintaining a car You may say best practice of maintaining a car is to make sure that you fill it with the right set of gas and Fill it with the right set of oil, but then what does that mean if you're driving a Tesla? It's like you end up with a different set of best practices for for it even though they are they're still fundamentally a car and so we need to be careful that we Don't fall into the same trap and instead we we list what is the principle? We we want to make sure this thing is well maintained or we want to make sure this thing as well Is able to scale or so on but then when we list it when we list the best practice that is is it based upon a High-level principle or is this something that is covering an implementation detail like if you're if your environment is If your CNF is multis and it has these conditions Then these best practices occur and that there's a set of appropriate conditions So that when someone comes along with something they want to install with with a Dan M or they want to or maybe something that Bypasses all of that and and adds it in with NSM Then you know in what context that best practice applies in order to in order to apply it you're getting with something that's a bit concrete and We can circle around and say the in order to achieve This principle these are these are requirements or our requirements it's a too strong of a word But these are best these are some best practices that may exemplify This particular property. It's not the only path. There's other paths that may be That may be appropriate that are not listed But there are things you can use as a as a reference to to get there So if if we're going to head towards that that practice we we may use something like that That could be something we could use for a framework. I Did put in a PR specifically for us adding a section for providing context Just because of what you were describing Frederick my main concern though is if we change Something and we say, you know, it turns out that this doesn't actually Support a principle like we thought it would right My big fear is is it'll be kind of like what we had in v&f's were like The quote-unquote best practices the requirements the standards etc weren't really feasible in the real world And so most developers rolled their eyes and just said I'm going to build what I think works, right? And if we yank the rug out from people a bunch, they're probably not going to take our group very serious Because it'll be impossible to adhere to So I'm just kind of curious like as you know, let's say we adopt Robbie's framework, which is fine with me I don't like Daniel would like to read it one more time, but um, let's say we go down that path I just want to make sure that we leave ourselves out that we have the ability to self-reflect and correct things as this space evolves if You know new technology comes out that maybe even makes us reevaluate a principle I would like us to like have a plan for that in advance versus, you know We get something that's broken later on and we don't have a way to self-correct Yeah, that's a good point. And in terms of something like Etsy, we have an advantage here because the things that we're developing As I don't believe this is a standards body even though we are even though it may end up informing standards bodies And this is an important distinction because when you start looking at what does it mean to be a standard That's where you have entire countries that have explicitly stated That there will not be any change in in this book within in order in order to make it reasonable and the end result Was that you end up with a lot of stuff upfront added to Etsy on the off chance Something might be useful as opposed to actively being useful And as a result a large portion of things that were listed within Etsy were never implemented They were just added in on the off chance that uh, that they may be useful And so we we should be careful in in this that we're we're not falling into the same Into the same trap because we want to list things that are common And one of the things that we could do is put a priority towards things that we see in In development or or practice where if we see if we're not seeing any active Implementation or we're not seeing any active Development but we're something that is aspirational Then we should explicitly state that but if we see something that is That is gaining a lot of traction And we write something that is a best practice surrounding it Then we should explicitly then at that point we we can treat that differently than Then something that has no actual implementation behind it so But yeah, that's that's going to be a challenge It's trying to work out how to how to ensure that you you get that that change and I think that's more of a process More of a process problem So one way you've got two things there. I think one is where do we source our best practices from again? You know what evidence we have that this would make a good best practice Um, and the other is given a best practice. How do we get feedback on it? So that if it turns out that it's counterproductive We remove it from our preference list So it seems to me we need to come back to critical point add a sentence around the process of approving A best practice or change it and just put some criteria around them I'm happy to propose a draft of that as well Okay, Robbie. I'm going to put you in the notes for that then. Thank you It's one B. Otherwise, I would be a rabbi Oh, sorry I don't I don't think from the if you look at the perspective of like cap the kubernetes enhancement proposals or python or Ruby rails where different projects that are have a healthy organic way of adding new things and Modifying new things. It's it's part of the process so if you Are saying that Some things problematic you ideally see it before it fully gets to the point of implementation as as a enhancement So for us that would mean before we endorse it as a best practice But for those that you don't what happens is they have a history on a cap and they go We're refactoring this or they'll have similar to rfcs you'll have a new one that comes out That addresses things that are missing And then you can also deprecate Likewise rfcs where one is completely deprecated and no longer recommend it I don't think from that perspective that we have a problem as long as we don't add additional rules and process That blocks those things ideally Anyone could bring something up and and start talking about an existing best practice and problems We can move that into a discussion Start working through it if we see it as a problem then We can move forward on potentially deprecating a best practice or maybe modifying it and jeffrey you've talked about adding context saying Where it may be a problem In some situations, but perfectly fine in others So that's something that we may Do after the fact you may have a best practice that everyone agreed to looks great And then as we get going either because things change in the world or we just hadn't had someone speak up you find It it doesn't work in some situations and we can always add to the best practice Content so that that's man Man, I don't disagree that certain groups do this better than others Like I said, the big thing though is there could be like Big horse corrections like anybody who's followed ipv6 for a really long time and kubernetes knows that like We all know that the shoe is eventually going to drop and it's going to be awkward like There's disagreement on how ipv6 should be implemented just networking in general, you know It was very web centric at the beginning and then other people wanted to use kubernetes for things and they're like oh now we need things like egress gateways all this stuff right and um you know, I would say that like kubesig and others have done a good job of You know addressing these but um that doesn't mean that like the transitions have been as painless as we would like them And like I said, even if we know that there's good models for us to follow We should pick one of those models and call it out because I've also seen other groups You know just assume that yeah, we'll be fine and then It didn't work out the way they wanted to like technical debt You know mounted up to the point where like maybe we just need to completely start from scratch things like that so Like I said, I just maybe some of this is a little bit of um anxiety based on past experiences, but like You know, I know at some point I have to Look at how we're going to do ipv6 and kubernetes and then we're specifically dual stack and Additionally, um, you know, I've seen other organizations where They didn't have a smooth process to you know, something like ruby on rails or something where it was much much more painful Or they just said it's not worth it We're just not going to change and everybody's going to keep running off the cliff like a limit Yeah, the kubernetes example also has the added constraint that they had some a single major code base to to work around with initial set of use cases in the standard kubernetes workloads that you see and We we're we're going to run into a few problems with that and that we don't have such a such a thing like We can't there's no reference Architecture that we will be able to point to and say this is the one this is the one path Like we're already seeing a A variety of different approaches that that are occurring we each with different set of of different principles and constraints that That are being Deployed and so like we that that's part of the reason I mentioned about the the conditions before as well Like if you're running in this style of environment then what are what are possible? What are possible best practices? But you also need a way to back up as well So as you learn more or the environment changes that we're not stuck with those Uh and there's also there's also issues around what What decisions have been made within a given organization? So even in a standard kubernetes environment when you start looking at things like best practices, you know You pick up something as innocuous as a cni if I choose If back in the day if I chose flannel as my cni versus maybe Open ship cni versus Uh something like You know some of the some of the other cni's that have come along with such as weave That they ended up with significantly different best set of practices even just to maintain it Much less how they've approached the development of their other environment and all of them were Were rational ways to approach it. They just made different decisions based upon their their requirements and and technologies and we If you if you look at the Best practices that came around kubernetes They ended up with three simple rules and those three simple rules were Nodes can talk to other nodes pods can talk to pods Nodes can talk to pods and as long as you met those three conditions then you're Has a cni Along with some of the basic contracts are added like you give your IP back and a couple other minor things Then you were pretty much set and good to go and it was hands off Primarily on how do you actually achieve it? And I think we're we're trying to be much more aggressive here and saying that well We want to state these are the best practices And then we say okay. Well best practices in in relationship to to what and that's why we want to start with What are the what are the principles like we want we want to be horizontally scalable? We want to be robust. We want to be And the question even comes down to why like Ian had a really great point from previous conversations We had that if you delivered a a box and that box had Met all of your requirements for uptime and you could access it through a very common API Do you care whether or not it's It's designed in a very specific way And so so maybe we should even get down to the what are we trying to do? Like we're trying to achieve certain types of SLA we're trying to achieve certain types of of ways to consume it through a Through a crowd-native API And then we can say if you are implementing it this with these constraints Then these are some of the best practices and go tap some of the communities to to go deal with that so we can go tap the The multis and the datum and the nsn communities and say well You're going to give us some examples of things that exemplify best practices and go and Talk about how those how those are approached and also other areas We can also take a look at them from use cases like the requirements of putting together a firewall or a vpm and managing of Kubernetes based firewall or vpm Are going to be much different from that's practice of surrounding. How do you maintain a evolved pack of car on on? your system the the requirements are are fundamentally different down to the point It's like what is the difference between managing an op a database versus managing a A microservice website that they're both valid use cases within Kubernetes, but they're substantially different in their approach that you have to make different Decisions in order to in order to ensure the health of the application that's running on it um, so So there's some things to talk about Wook speaking one comment on The depreciation of the best practices. That's a very valid aspect that we have to take with Very carefully and very seriously especially due to that Past experiences not only with with etsy and vnf, but many other approaches like that Uh, this was one of the reasons that motivates me to bring that first point in As long as we have a concrete functions and concrete pieces of code in the discussion and having a bidirectional Dialogue or Being ready to depreciate the deprecate certain Best practices if in the dialogue we found out. Okay, it's really blocking a meaningful things and it doesn't contribute to I don't know better sla or better uptime and and and so on Then it's up to community to really Focus on deprecating that but we will only find or mostly find that By confronting the rules with a concrete example the problem with etsy Was that there was a lot of writing in a point in time as Was rightfully said and that there was no willingness on consideration But we were just pushing On just pushing but there was a lot of like, okay. This is a framework. Please fit to that and then the the feedback from the developers that Was said here were rolling their eyes this rolling of eyes Didn't end up in the process of Reviewing does that what we do? Or what they do there makes sense and how it has to be Revaluated that's Very important to to Factor in here and another piece That that was mentioned Is like black box thing and I reiterating and I was reiterating in a in a chat There could be a two purposes of that one is completely developer centric and that should go like how to use cloud native patterns and how to Use Kubernetes to the maximum and and Possible extent to make a best function package it in the box and deliver it From the operator side from the side of the of the Actors that are consuming that That's to call build a black box. You can put whatever azix proprietary hardware in it. That would be all all same Uh, the other approach or other way to do that Is really saying, okay, do we as operators i'm talking from the operator angle what want to establish a generic cloud layer for those functions and Onboard the network functions on that cloud layer And give the functionalities and the possibilities to those functions to be able to to run As they were supposed to run and I think the The value of doing a cloud native principles is at least for for that perspective Of operator that I have a generic or more or less generic infrastructure that runs in x y set locations And the cns are onboarding on that one and The set of best practices is a contract Is a kind of sort of contract between these kind of infrastructures and cns Just want to uh wanted to reflect on that because for a black box um I think blackpost whatever it is inside. Nobody wants to care Except developers who are making the black box to be the best possible Speak speaking as the supplier to a bunch of very inquisitive customers. I'm not sure that's true, but um Perhaps what we're saying here is rather than the What the document currently says, you know We will define best practices in light of other people other definitions of cloud native We should say we will define best practices That's one avenue of attack, but we've got other things to deal with as well I think we're ruling things out that we should have within our remit What exactly do you mean by that? You can you rephrase it? Well, what specifically are you concerned about that we're leaving out or that you're thinking we're leaving out So, I mean we've the points keep coming up They're right that we don't have a platform definition Because we don't know what a good cnf is You know a well-behaved cnf following a standardized and singular platform definition as an example um, we talk about cloud native as if it has Meaning without context, you know the words mean we know exactly what a cnf cloud native cnf looks like and those principles exist elsewhere and I don't think they do so um, rather than saying We will do the lowest layer of this we will do the the implementation the thing that describes Here is a c here is a cloud native best practice His here is how you demonstrate that it exists in a given cnf. We also say here is Not just the test for the thing we're looking for but here is why that thing is a best practice in the first place Here is our thoughts on why it should be a best practice not necessarily um You know hoping that turns up in another group those the why why something should be a best practice is explicitly part of the proposal process so starting with The discussion board so you're discussing something and The discussion board of course can be other things so we have like the actors and stuff but The when you're someone is bringing up a potential best practice or maybe within a discussion It is ideally part of the conversation Would say here is why we think this is a best practice Yeah, but if if I were writing software In an old-fashioned way and you know, even if we're doing agile this still exists, right? We have requirements design Implementation the implementation meets the design and the design meets the requirements but What we have here is implementation With a bunch of hopefully some requirements thrown in for good measure But that means that you know individual best practices are considered individually not necessarily sourced from the same Set of you know a consistent set of requirements or a consistent idea of design You have to build down to The level what we want to be at here are testable things we can examine So we're not doing this in a vacuum, which it sounds like you're implying that well That's true, but I've asked before what are our where's our design? Where's our requirements coming from? If if we were building all of this from scratch if you just came in and said we're going to build software and Operators just start using it and just you want things to run. Okay. That's all we we're not doing that We're not we're not starting completely from scratch. We're we're building off of Existing applications. So that's related to putting the discussion forward on c&f candidates So that's working from that level backwards We've already listed in the actor and hold on a moment in the if you go look at the actor discussion one of the items that was brought forward was platform Developers or vendors whatever you want to call those wherever they are So those people would be involved architects designing from maybe within the a A add an actual Service provider that may be designing the overall architecture So you're going to have all of those people engaged But it doesn't mean that we have to have all of that done before we even start because we already Know that part of it's going to be based off what's out there So the the bgp speaker are we going to say those are no longer useful immediately? You'd probably argue that those are going to exist for a while or a I'm fine Yes, if you want to design this stuff And you're a little bit short on the on the y of what you're doing bgp speaker as an example, right then Where would I put down the why where do I put that down and I don't mean as as In the same way that I try not to write code and hope everybody understands what the requirements were that drove me to write it I'm saying Where would the abstract requirements go when we get those actors together? Or where does a user story fall short on your why? If you were to capture what you're saying in the user story the user's pain or whatever it is right now for bgp to be explained for the first time in a What is looking to me like a test or a test description? Is my well we're talking about the requirement the driver for a requirement So if you're out there developing any system at all And you go out and you get user stories, right? You say this is a user. This is what they're doing. This is a problem Whatever it is And now you're going to build your requirements based on that user story Where you got the requirements, which could come after the user story You can look at the user story as a requirement either way But what where are you not capturing what you you are talking about? I'm really saying that the user story stands independent of the conclusions you draw from it Yes, that's correct. So you have the why in the user story. Are you saying the conclusion is the why or What are you saying? I'm saying the conclusion stands independent of the user story So if we have a user story, would it not make more sense to keep it separate from The conclusions we draw from it rather than embed it in every single conclusion because The proposals we seem to have here The the things we will be filling out as templates are conclusions recommendations the final the final element of the implementation So fair enough if you were so if the user stories were separate Right, but you referred to the user stories and that's what we say Okay, here's our why you need to have a real world description of something you want And point back to that and then you have the and then you point to it instead of having it in Directly embedded in there that would kind of satisfy what you're talking about Yeah, effectively Having a home for those things Um independent of the the things that we the recommended, you know tests or things to do and tests that satisfy that user story Having the user story stand independent because I think that means that the user story will be more Yeah, fine. It won't have conclusions of its own, but it will be hopefully something that people who don't necessarily care so much about Exactly what we're testing about the cnf. We'll actually be able to read it and make sense of it Yeah, that makes sense and user stories and then maybe even surveys that go with the user story like someone can write up a user story And we can kind of figure out How how many people you know relay or that were user story resonates with them and their business and stuff like that And we can kind of have the the drive behind the user story how much agreement we have with it and then the These other principles we can kind of you know work at it from both angles You have certain principles of cloud native principles so on so forth And we say okay. Well if you're wanting to have this type of architecture and these types of trade-offs that go with this architecture Are they compatible with this user story? No drop them off. You can't implement it or you can whatever And it seems like that You know, this is a you know a cat and you know chicken and egg situation That's it's which is fine But yeah user stories seem to me to capture everything you're talking about Which is fine. I mean if we're coming back to you know Our repository my point would be that they deserve a directory of their own I think And a process of their own as well I like our idea Ian of having A whole set of user stories that people can contribute to and and maybe more than People just being able to find it separately would be people that want to contribute user stories But don't really know it they they're maybe they're Have more experience on the user story writing those and less experience on Helping with build the best practice or discussing the implementations So it helps with that. I don't I wouldn't want to stop people from getting started. That was the whole point with Doing this which ties in with Having the user story embedded But I would say whether if someone if someone well if someone starts a proposal For a best practice They should it's it's required actually before it's going to make it that they need to tie that to the user story Yeah, and that can always be copied out If someone starts with the user story Then great just go to the user story. I'm just saying let's do both and and we can get started Yeah, that's fine If you consider what we have here, we have a git repo and every git repo I've ever worked in you can commit two changes In two files at the same time So if you've got um a best practice you wish to recommend against the user story that no one's ever thought of before You can commit the best practice and the user story in a single change It just isn't in a single file anymore, right? You commit the best practice and the reference to it in the user story, but it gives you Three options there or other than one I can commit a best practice based on a user story that somebody else documented I can commit a user story Even if I don't know what best practices that implies and I'm leaving other people to tell me Or I can commit the whole thing as a as a chunk and people can review it in that light Um Whereas what we have at the moment doesn't seem to leave us with quite those options Yeah, um You know, I think I see what you're saying. Uh, I see what you're saying Um, would you want to come up with like a proposal similar to Like robbies for the usual user stories? um Yeah, I think we can build on rabies patch and we can say, you know, we we take two streams of information This part is our our responsibility is x this part of our responsibility is y and here is the process for both of those things Um, so if we start there and then we want a template for what a user story is including audience and so on Um, which would be the next part of that Okay, perfect. Is there a Would it be all right if we um get this merge from rubbing in place and then do a new pr on top? Um I'm not sure. Um I want to read what rabies written a bit more closely before I say yes to that to be honest. Okay. Well, I'd say Go to everybody that's interested in helping. Please go through the pr And let's try to get it merged We're we're not trying to get something perfect today or this week And and it's sitting there. This goes back to the comments earlier about what do we do if there's a best practice that's Needs to be updated None of this should be thought of as final It should all be thought of if We're doing we're doing what we understand to be best today and we're going to keep updating it every day going on But if there's something in what's currently there in that You think needs updated. Okay But ideally we can keep having smaller prs that get merged sooner Um, so they're available Yeah, I mean, it's certainly in the future. That's obviously the case We're trying to make this so that everybody knows what self-contained change looks like so that makes more sense Right now we're busy defining our outlook on the world. So um While I think I'm all right with what rabies saying I want to read it more properly because I don't want it to be You know, I want to make sure we're getting somewhere in the right direction Uh, plus it's got a few spelling mistakes in that one fixing which is also making me it's making my ocb go off. So Sure. Yeah, so I think it'd be great if we can all take the next week Um to review rabies pr and then we can continue the discussion Then um, so thanks everybody for joining today. I really appreciate the discussion I think you know, I really appreciate your idea on splitting the user story and the Best practice from each other So thanks everyone Thanks bill. Thanks again Cheers. Bye. Thanks. Bye