 Hey folks, hey Tom, looks like we have a small group today. Yeah. Is there a holiday in the world somewhere going on? Nothing listed in my calendar. The main European countries that I do with. Well, other than the task for documenting the process for publishing CNFS practices, what do we have today to discuss? So I could see from last but you put in third. Hi Victor. Hi Oliver. Hi. Hello Taylor in the morning. All right. Anything else to add to the agenda? Nothing for me. Someone say something in chat. All right. I don't know if it could be a good time to check the discussion topics on the Github page. Maybe we can just take a look and see if there is something that we can bring to the table. We can get started on this first one as far as documenting the process to publish the best practices. Last week kind of went through quickly with a few things but didn't organize all of it. Let's see. This might be helpful though. What is the process? I don't know. I'm not even requesting people to start by understand the mission statement. Might be a good idea. What else do we have? I know that at one point there was some slides. Let me try to see if I can pull that up. That we're doing this introduction. But I'm not seeing anything in the repo for the process. So while I'm looking for the slides. Introduction. Let's see what it is. CNF working group. I think it was with Jeffrey Saylence and Ian for maybe for KubeCon a year ago or something. I don't know. KubeCon CNF working group. They have found them. But this could be an old copy. Let's see if the process is actually in this. Hey, look at there. No. It's very short. This may not be the right copy. Okay. Hey, look at that. Add new best to find the excuse. Socialize an idea. There we go. We talked about this many times. I will change instead of existing PRs for open PRs. I mean, minimal change. I think that's kind of. Part of just general contributions versus. A new one. What can you do, but yeah, socialize. Open PRs. Yeah, but technically you cannot make a comment. On close PR. So. Open PRs. You can actually, you can make comments on close ones, but people may not see them. Exactly. Yeah. You can make comments and closed issues and everything. Yeah, that's really. That's really helpful to make sense. Make comments on it. I don't really want to say open new PRs to socialize an idea. I can just remove this if we want as far as socializing the idea. It's probably not good to do idea inside of it. Yeah. PR. Is that good enough? Yeah, that's good. Hey, why did that do that? No, that's just great. Great. A GitHub issue. Seems like we should promote people. I mean, recommend people create GitHub issues. For. New practices that are. Input forward. So once it's through the. General brainstorming and all these other places. Create an issue and say, here's one. Non rate in containers or privilege equals false. Recommend it. I mean, could, could we add that to the list on the. I am three. So do people have to start. We can socialize and discuss within. The GitHub issue itself. So someone's got an idea for a best practice. And I think it's valid for them to create an issue and. It can be discussed within the issue and then it's either taken forward with a PR or. Or we decide to agree not to adopt it as a. That's a practice. I'll put, how about like this then. Optional. For these top ones. Yeah. So someone may, the reason why I have these others. I think it might be. Sometimes that might be too. We should. It might be too general. We should secure the containers. Yeah. Yeah. What do you mean? Don't allow privileges on containers. Okay. That sounds a little more specific. But what do you mean? Oh, we mean. Don't allow root. What about, you know, running the. Run time privilege, you know, just on and on and on. Oh, okay. We can break it down. Each one of those sub one should be their own issue. But they may not be ready. But if they are, go ahead and create an issue. So Taylor. Well, what is going to be the criteria for. Open an issue versus open up here. I mean, me, from my perspective. When you create an issue is like. So you're reporting something that you don't know how to do it. Like in this case, probably. You are. Suggesting a topic that you don't know what is the best practice or like, what is the use case, but at least you raise the hand. On the other hand, a PR is more like a, I have, I propose in this, this is my proposal. This is my, the best practice that I am proposing. And I'm just need feedback of that specific proposal. So. But in this case, yeah, what could be the, the criteria choosing between an issue versus a PR. A pull request is. Suggested changes. To the repository. That could be like a whole set that could be partial updates. You could have a. A change to existing best practices or improvements. And the issue is to track. The best practices. You have larger amounts of that, or it's a higher level. So you create an issue and say, here's the best practice. Well, now what do we need to do? You have. Maybe you. The PR is. Related to that best practices, adding a. User story. That provides context. Then you create another PR. And then you have a list of the best practices. And then you have a list that references the user story. So you could have multiple PRs under one issue. But the issue is communicating where you're trying to head. With the best practice. If it's a brand new. Best practice. Versus a. Well, I'll just, I'm getting specific. I'm going to say in general, it's good to have an issue. What are the best practices that we have open? What are the best practices that would close? And. If. You know, with tagging and everything. It's something that would. Pull in all of those. Versus the PRs could be all over. You could do spelling. Fixes across two or three best practices. So for example, one of the. I don't know best practice that I have in mind is. What are the best practices that we have open? And try to avoid. Static IPs. So. What could be the workflow? Like. Should I need to start that discussion? First of all, in the, in the. Discussion discussions section or like. Just going directly and. Open an issue. So. I think it's partly. A preference or opinion on that. For myself. I. See the benefit of having the entire process. So that people can see how it fits together. And if you're stuck at any stage, you can jump in and help, you know, put it in there. If you. Don't know where to start, you know, many reasons. So have that process. And then I personally think it's okay to jump in. Anywhere that you can help. As long as you recognize that. You know, there could be areas where. There's missing stuff before or whatever else. You know, then I think it's fine. And then other people may want to. The way that they, their process for work. Or the way they work through things. They want to start from the start and move forward. So. If you already have, you know, this idea for this. Don't use static. Are you saying. Don't statically configure IP addresses on the CNF. Yeah. Okay. So. You may already have enough information to feel like you can. Create an issue. And say, here's some references already. Yeah. I mean, you may already be ready to write the pull request. Because you have so much document. That's fine. If in that case, I'd say create an issue. Have the quick summary and the issue and then, you know, you could put a PR in to draft. Otherwise, if you don't have something drafted yet. Then create the issue. Add the summary. Maybe, you know, you add references and say, here's a bunch of places where people have said. You should not statically configure your IP addresses in your application. You should allow it to, you know, be dynamically assigned. Then you build all that into the issue. If you think it's a good idea, but don't have any content yet. And you'd like to get more people talking about it. And it's, you know, you're just not sure that's where to start. So you might want to start with, you know, the first socialized idea. And you may. This is, this is kind of open between three and four. Someone may. Not. Know if it's a good idea. And not realize that the whole working group already would agree with them. So they could have jumped ahead. It's okay then. The first socialized idea. You know, you know, you know, you know, you know, you can believe everyone's going to agree with you. And you create an issue and people don't, well, it's okay. We'll discuss it in the issue. So I think three and four. Are kind of open. And I personally don't care if I don't know if we're here yet, create a. Pull request. I'm not going to be real happy. I'll, you know, I'll probably be just happy that we have some contributions. We may go and ask, can you go create an issue for this so that we can track any, you know, comments and complaints or any, whatever it is. The issue is good. To have pull requests, comments and content in pull requests kind of disappear. So I think we'll end up not going back as much to see a pull request as an issue. Like in an issue, you may paste in. Diagrams and images and other stuff. And that issue could end up getting referenced. The pull request is probably not going to get referenced as much unless it was a big code change. And someone was like, Hey, look at this big change that we made. Is it really important for this reason? Anyways, I hope that helped. Definitely, definitely. I mean, you mentioned something crucial, I guess, I mean, especially if you have references that it's going to be the mayor distinction between socializing an idea and. You know, an issue in this case. Taylor, are you saying something because you're on mute? No. Sorry. Sorry. Going back and forth trying to put this together. So. What's underneath here that can be hidden. And that's a problem with the process is. Someone could come in and just work on user stories and use cases, which helps. I don't want to stop someone from adding more use cases and user stories. But I think that's a, you must. Start with an idea for the best practice. If it's related to existing or it's. It's like a set of best practices and that's fine. But I'm trying to keep it focused on. The end goal of publishing a best practice. I think that's what. We haven't had as much. Forward momentum on. And I think that's what Oliver, you were. Referring to last time was. The process specifically for best practices and not all the other contributions. Yeah, correct. Kind of want to separate this. This, this line here, I think is important. I think it's important to have people. People. Working icing. On the other hand. We've had people throw stuff over the wall, so to speak, and then disappear and then expect it to go through. And they're not, you know, helping with. Something they put there. I think there's. There needs to be an expectation. If you're the one creating the PR. If you're the one. Providing the content for that. Yeah. I think it's okay to. Create an issue and then. Not necessarily create the content. Yeah. Agreed. Or a discussion item. Yeah. Like, here's an idea. I saw it on the internet. Yeah, exactly. I agree that if you create a PR. Then we probably need to have some kind of stale. You know, You know, Yeah. Responding to comments in the PR. Merge suggestions. When. This is another thing where we end up. Getting stuck is there's a bunch of comments. And sometimes even suggest edits. And then they just sit there. Yeah. Good chairs. I'm just putting this in there. It's not hard rule written. And. Close out PR switch. Stalled. No progress. And submitter. It's absent. Maybe we can find like. Like a good action to do that. I have seen. Yeah. That's, that's, um, I'm totally fine with it. Victor. We need to document. Whatever the processes. Before we automate it. Why are we automating it? Why do you put that for them? And then if it sounds like we all agree, this is a good thing and we can automate it. Then I'm all for automation. We got focus elsewhere. Regarding this step. Does that mean that we are not going to check any PR? If that is not included in the agenda or like, I mean. It's like highly recommended that. The submitter. Add that to the agenda too. I mean, because I guess usually. We take a look of all the open. PRs. So. It's more like suggestion, right? If you want that you PR. Have some visibility. Just add it into the agenda and we can discuss it in the next weekly meeting. I'm sorry. Your audio like partially cut out for me. So. No, no, no. Well, the thing that I was saying is like. For me, this. The. The sentence regarding the. Adding the. The PR in the agenda. Seems more like. Suggestion, right? Because essentially. Every single week we're going to discuss all the. Open PRs and. Even when they are not included in the agenda, right? So. One way to. Increases the chances to merge that PR is adding that. Into the agenda to make sure that it is going to be discussed, right? Or that means that. We are not going to discuss. The PRs. Even when they are open. If they are not included in the agenda. So. We can definitely discuss them. This is. I am. Putting it in here as part of the process. For publishing new best practices. Okay. This is separate from what. Will the working group do to run the weekly meetings or anything else. There's overlap between all the work that we do. But what is the process of someone is coming in and wants to publish. What is the process of the work that we do on accepting or rejecting at some point. So there's a, there's a PR saying, here's a best practice. Okay. So what do we do on the step for acceptance or rejection of that PR. We need to review and discuss it. And I'm putting submitter, please add. I'm adding this in here because I want, and this is like a note. I mean, this, this is all of these steps. I'm not going to put it on the repo. But right here, I'm putting it here because. I want people that are submitting ideas to actually be present. Here's your pull request. We'll then add it to the agenda. Like proactively at it. So it's on the next meeting. And then you're saying, here's the night, or whenever they're going to be able to join next, add it there. Yes, you or I or. I'm not going to make as much progress. So that's why I want comments like this. All right. For people that are proactively trying to move stuff forward. We probably don't need all those extra little words. These words are for the people that either don't know, or haven't been actively helping. So that makes sense. Victor. I'm being explicit about the parts that I thank you and some other folks that are already contributing. Would take for granted. One thing we could do is. Maybe just create a dead simple pull request template. So when a new pull requests created. The question is asked of the person creating it. If they've added it. And I link to it to the upcoming meeting agenda. Just as a trigger. As well as having it in something like contributing. So. And the. Have it where they're going to see it as they're moving through the process. Yes, I have it in the contributing file or whatever file we put this process in. But on that specific point about adding the PR to the upcoming week, the agenda. We could create a simple pull request template. So that when a pull request is created. There's a text in the body. Of the pull request asking them to. Add a link to the pull request to the meeting agenda. Sounds good. So there's a two. There's a lot of places that we can do it. So part of it is. In the pull request template. Yeah. We can actually add. And I don't know if it's in here. Yeah. And there is see this. So that this stuff is not going to be visible. These, these comments won't be visible on the final. But you can actually put something in here like as a reminder, after you submit this, please go. Add it to the, you know, whatever. And then you can have the automation as well as part of the. Work flows. So we can, you know, have something here that maybe. I don't know what's possible on the GitHub, but if, if it says. Your, your PR has been created. Please go do this. Would be good as well. Yeah. Yeah. Actually, if I remind correctly, there is a way to create a message for first time. Contributors. Yeah, we can also add that. I'm going to say respond to contributions. On to first contra contribution. What else? Well, in terms of doing something about this. There's, I think quite a lot of what you've listed there is in the contributing file already, but maybe. Over different sections. Is it worth a couple of us having to look at that file and see if we can make it. Simple to understand. Especially those top. Top three or four points. Yeah, I don't even want to say it must go in the. Contributor. Document. The contributor document may be more general contributions, but we can have just a section creating best practices. Whatever it makes sense to put it in. It's possible that we want something like a. You know, just put something under the docs. Folder for that. Specifically, here's the process. Outlining. Yeah. You know, this is kind of a high level. General word of contribute. You know, best practices like this one, what to contribute. We could have this go directly to something. See, this says CNF best practices. It's going to the, what would be the list. Here's the template. We could have a link here that says process for contributing best practices. And then you click it and it brings you to a new doc or it could bring you to a section in here. Whatever, whatever makes sense. Contributions. Yeah. Okay. We say where to go. I'm going to put them off to that. How to talk in the meetings. Yeah, I think this one's pretty good. If you're going in and saying, I don't know how to do this, like I've never created a PR. Well, we have some general info. On that. Yeah. Probably need to link over to the. Get have docs for how to create a PR stuff like that. Should I create an issue. For documenting that you just listed in there. Yeah. If we don't already have it, we may already have it. If, if not, then yes. All right. So Taylor, usually. When before create any pull request for issue. There is an a step which verifies it. If the pull requests, it is there like a something like us. Make sure that there is not an existing. PR discuss in the same thing. Right. You want to mention that as part of the steps. Sure. So how's that for some info. Around existing best practices. I guess a good qualification. Yes. We're not going to cover all cases. We're going to put what. We think there's going to help us and help guide people. And then we should set our expectations that. People aren't going to always three and they will. Do open stuff anyways. Some people are going to ignore it and do what they want. And we also want to not lock things down so much that. We block people that legitimately are trying to help move stuff forward. Yeah. So there will be. A requirement. To manually review and talk through with folks to. Try to move things forward or. Sometimes repeat and say, yeah, we've talked about that. Here's all the references on why we didn't do it. I'm just expect to do that sometimes. Yeah. I've got a drop from it. All right. Yeah. I feel like there's something after this may be published to the. There's a. Publish to best practice less. And get. By and. From the. Co-chairs. I don't know what's next. So there's probably a few more things. Thanks everybody. Thanks. Thanks. Cheers.