 Absolutely. All right, folks, well, while Diane does her thing, what I wanted to do is bounce back over to this discussion, which is the item about community support. So we need to come up with some language. And I'm assuming the docs folks would be the ones most appropriate for that, at least to have a template or something that we can bring the larger group. So we could put it in actually in the discussion here and modify it or we could do it as something in GitHub, as just a document in GitHub. Any thoughts on that? And again, to provide context, this is again to clarify the support model for OKD because we've seen a significant uptick in folks reaching out directly to Red Hat employees, in particular, Vadim, asking for support. He got another email a couple days ago from someone directly asking for support. And so what we want to do is make it clear. And this also has the benefit of sort of inspiring folks to become a part of the community because they can see that they can help others and they can see a way in which to participate through helping others and answering questions and whatnot. So what do you think? Can we do this in the discussion thread on GitHub? Or do we want to do it as a document and folks add edits? Or do we just want to do this in a hack file? Or how's the best way to come up with this text that we want to paste everywhere? Actually, I have a question on how could it not be clear? Like I think the support model is the same like going back to Slackware, which is like where I started free kernel 1.0. With any open source project that had companies attached to it, the support model was always that the companies weren't there. You bought it and if you were going with open source, you supported yourself and you could ask questions and people might help you depending on how friendly the community was. So I'm not against clarifying things, but I think it would be hard for any living person not to already be clear. I don't know the answer. Like where do you go? Okay, so I think that clarifying things is maybe not enough because no matter how well morals are understood, you will have rude people. So then the question is what do you do with them? So what do you do is correct them or generally bring it to their attention. Right, and that's what this can do also is it gets ahead of things, but it also allows us to point to something for the people that choose to reach out directly or choose to somehow because it's also going to clarify time. That's everything I should mention is this would also say that as I've posted in the channel to folks before is that this is as available as people in the community have time available. So this is something that we can point to after the fact as well. So if someone mistakenly, let's say mistakenly thinks that it should be Vadim or the Red Hat employees or mistakenly thinks that they have to be responded to at that moment, then we have something to point to and say, well, here's this statement of our, and it's only a couple sentences, but a very concise couple sentences that lays this out. My thoughts, I don't know. Mike, what do you think? I mean, I think this is like a really tough situation in general for open source communities, right? Because like on one hand, I totally agree with Bruce. Like there are no matter how many messages we put out, no matter how clear we make it, like do not contact these people directly, you're always going to have people who are still willing to just write an email directly to Vadim to try and get his ear, right? And I certainly don't want to put any of this on Vadim to say, hey, Vadim, you need to tell people no more often, but certainly it has to be okay for Vadim just to ignore these emails or anybody to ignore these emails. Yeah, like I would like there to be a place where we could direct people. And maybe there's also a behavior pattern that we need to accept as well, which is like, for someone like a Vadim who's getting a lot of bandwidth on this, there needs to be an easy way for him just to push a button and redirect that person to, you know, input your question here, create an issue, do something. But like, yeah, Vadim is not your personal enterprise open source consultant that you can just email anytime, you know, like we have to make that not acceptable community behavior. Right. So it might be that we have a paragraph blurb and then a page that's literally like the three things for support, and there's nothing else on the email list, the channel and putting an issue in, right? Like those would be the three ways in which someone can get support. So literally just a community support page, right? And then we have a paragraph and then that paragraph of three sentences just contains a link to the community support page. And that's it make it that clear, you know. Yeah, I think we have to have a link to the issues form like right there because like if someone's gotten to the point, yeah, hey, and hey, welcome, Michael. Like if someone's gotten to the point where they're already writing an email to Vadim, like that person needs to like, control Z on that email, or like control C and control P all that stuff into the form for the issue instead, you know, it's like we need to get that to be the pattern of behavior. Right. So the other thing I would add in here too is that there's a little training on Vadim's part two. And I think we all fall victim to this, that we want to help. Right. So Vadim in the past has answered questions that probably should have been answered by the community. So there's a little bit of training on the part of the Red Hatters as well. So, you know, and, you know, we all want to be heroes too. So and solve people's problems. So I think there's a little bit of a tough part here. Yeah, that's that's the hard part. And then our day jobs get in the way. So, and Michael Burke, thanks for joining because I was trying to remember who was the Michael B and all of the Michael B's and Rover to see who was working in docs. And I couldn't come up with anybody that worked. Sorry about that. That's all right. Now I know. So that's that's good. So, Jamie, I really like the idea of having a support page. I think that's that's helpful. And and really sets it up. And the more we drive people to that Google forum or to the to the Kubernetes OpenShift users or dev, the better off we all are because there's more people there to answer questions other than Vadim. So and the quicker we are to respond, like as in before Vadim wakes up, I think, you know, there's that's that's going to be or Vadim or whomever, Mustafa or whomever steps into the foray as we, you know, go on and mature. It's also training the Red Hatters to to say to pause, take a breath, and maybe forward it to someone they think could answer it, whether it's Jamie or Bruce or or John, John Fortin or or Joseph saying, Hey, could you take a look at this? So there's Vadim has been forwarding email to the working group, actually. So he has been doing that, which is good. We've broken him. We've broken Vadim. So it's and if you're listening to this Vadim, we hope you are healing on a vacation cruise. And we love you. So I think it's going to be as a point, but this happens in every open source community is that, you know, the founders of, you know, who else now is a CTO or CEO of a some startup will answer something. It's just for, you know, you'll get. Yeah. But anyways, I think the proposal that Jamie has about creating an maybe and I'm thinking on OKD.io and explicit support. And this is what you get. And this is all you get, right? And maybe at the bottom of it, general surgeons warning. This is a community sort of supported initiative. It is not, you know, yeah, whatever. But like the general, I think that's a Dan. Yeah. Just to follow up something else you said, though, that because you mentioned hero and be aware that in absolutely every single hero myth without exception, the hero dies. Absolutely. Yeah. Absolutely. Hopefully the hero gets to retire in our storyline. So yeah. So it's probably not a good one to emulate. Yeah. So the thing that is not they don't get to retire, they get promoted and go away. And then we have to reframe somebody else. So the more we should we switch over to Michael Burke's and handle that. And I mean, maybe we can come back to this. Yeah. Yeah. So and I'm just going to blather on again, Jamie, even though we said you're running the meeting. So Michael, one of the reasons from last week's full working group meeting that I expressed was we would like to be able to do some pair reviewing this like, like pair programming type thing of the OKD dot, the docs dot OKD dot IO stuff to start with, with Mustafa, who was just joined Red Hat, there's about, I don't know, 16 or 17 new Red Hat engineers that are going to be run through OKD working group over the next six months. That's we are the training ground. So we're trying to find good tasks to train them on. And one of the things and I think I said this last week, so I know I'm repeating myself, is to take someone who's experienced deploying somewhere and pair them with one of the newbies and walk through the documentation to start because there are things in or I remember seeing things in docs dot OKD dot IO, because it's just generated from the baseline OCP docs that were references to things that were inappropriate, like rel corOS as opposed to Fedora corOS or some some form of support did thing that we don't, as a community, have access to, whether it's some cool operator that we we lust for, because that's where we're at, or, you know, something, but just trolling through a section of the docs. And the questions we had in where we wanted your participation was, if we find them, what do we do? Right? What's the best way to communicate them to Michael Burke and the docs team to get them fixed? And that's what we don't know. And what I was thinking was to do a three way pairing, so a trio, and have Bruce, Mustafa and Mike do one section together. And then, Mike, you could say where you wanted it, you could see what they were finding and see what kind of issues tracking system we should either set up or use, always remembering that some of these people are going to be external to red hat. So that's the caveat with the technical documentation that is docs dot OKD dot IO is that is generated by red hat for us. So I'm going to stop and tell me if you have any background in or ideas about how that workflow might look like that would make those changes happen rapidly. Probably the best way would be to do an issue in GitHub. There's a label that docs only. There's a label in there I can search on. Yeah. And who's watching that, I guess? What action does that trigger? Is anyone watching that? I don't know that anyone's assigned to watching that expressly, but I can make it a point to do so. So and the docs, they live in the OpenShift GitHub repo? Yes. Yeah. So maybe I don't know if you could do me a huge favor of sharing your screen and going to where you see the docs and where that issue would be logged the best place. OK. I think there might be a caveat in there somewhere. Cavia. I can figure out where it goes to go here. And thanks everyone for bearing with me on this one. I've seen multiple sets of docs in my time here. So. It's good for us all to be on the same page and kind of understand where these things are. So I appreciate it. Well, I'm going to get more water. I'll be right back. It's two feet away. All right. Can anyone see my screen? Yep. I can see it. Yeah. So this is what I was thinking anyway. OpenShift.docs repo. Find an issue here. And I'm going to slide to that for a while and it gets a lot of updates. That gets a lot of tickets in on it. Yeah. For sure. Yeah. Click on that OKD only of that one. See what we get. Zero open. So now the other question I have for you, and this is really just me being redonkulously naive about how docs are generated. If you go to docs.io.okd.io and you find an error, where is the source for that? Like. It should be here. So like, is there one that's, there's an OpenShift.docs and then there's a repo that is just OKDs? No, the source is right here. Well, it comes from here. So there's like just a different make target for the OKD docs or something? Yeah. Yeah, we use, we use a gift def statements to qualify something belongs only in OKD or something doesn't belong on OKD. So if you just do me a favor in one of the, another tab, open docs.okd.io. And let's just find something that is OKD specific. Oh, we're doing OKD now. Docs.okd and click on the documentation. I'll take you right there. Like the version, the latest. Oh, this would, I believe, I think this is specific. This is specific to OKD. So if I found something, like if you searched in here for CoroS, I'm just trying to find something to make one. And of course. Or just Fedora, maybe, or CoroS is the thing that I think is. You know, it's something to this page. It's different. Yeah. So you know what's new. This is the regular OpenShift docs. Yeah. So now you're in the OpenShift that you're not in the OKD you bumped down. So this is the OKD doc. Yeah. But it's tight. This book is not in this book is OKD only. All right. So the So this book was made from the OCP stuff. Or is it? Yes. Okay. So let's, let's, I mean, I'm just trying to find one thing that we could make, log an issue on and see what happens. So you can do a quick search on our costs, which I did on the OKD docs and a handful of items come up. For example, I'll link to one that just hasn't mentioned our costs in it like right there. Yeah. There's one in here. So if you look in the chat, Mike, you can grab just go straight to that. Thanks, Jamie. Okay. What are we looking for? Somewhere on this page. Our costs there. Oh, it's an output nasty. So So part of it is so that that sample needs to be rewritten. Yes. For us. So and would it be node dot OKD dot IO slash OS ID? Or is it just node dot open ship dot IO and then F cause anyone know? That's a good question. Actually, you have to look. Yeah. So if we so let's just do it this way. So Mike, if you were going to log an issue to have this looked at and reviewed, how would you do this now? Would you have us do it going back? Um, yeah. Back into the GitHub. All right, so many tabs open here. Where you go? There you are. Yeah, go back into here. Take out a new issue and fill out the little template there. Give it a good title. Okay. And then let's let's do one. Let's tag the example is incorrect for OKD. You know, on this page. And I guess my question is, can those labels be added by the submitter? Or is is that something that has is done after the fact by a reviewer? Can we fix it? Or like I don't know. Good question. So then you just take that example. And then take and put in the link that is that Jamie gave you example, example references. Our cause and then grab the link to the directly there at the top there. I think the example needs review. Um. To know what to change it to. I could just be it could just be as simple as changing R H C O S to F C O S. But I have a sneaking suspicion that the example might not run if we just did that. I'm not sure that there's three other guys on here who've run this stuff before. Yeah, that maybe I haven't looked at those labels on the nodes for for F, you know, for an O K D, like I'm too used to using O CP. Yeah. It's log in. Let me see if I can do it real quick by logging into one of my O K D close. Yeah. I mean, if either of you has an O K D cluster, you should just be able to get nodes minus O YAML and see it. Right. But under what needs fixing, you don't need the solution. Do you need the problem? If if we have, if we have the solution, we should make it we could replace X with Y, you know, or something like that. So, you know, if you know it, but I think this is where someone in documentation might not know the answer to this, you know, I'm not sure, but I don't know it. So I think it's the simple and then it could be apply the labels to this. Just the kind is documentation and then maybe add O K D only as well. So you get two labels on. Yeah, for bits and grins, assign yourself, Michael and me, and then we'll see then we'll see what happens. I'm not sure. And I'm just, I'm just D Mueller. 2001. Yeah, there that would be me. Yeah. Just for reference sake. Mike, Jamie repeat. Oh, that was me. I was sorry. I was just saying that I was checking out this, the issues on this repo to look at the labels. So Michael does have special permissions on this repo. Like, I, I'm not able to change labels if I create an issue. So this is something that, you know, someone who is going to be able to triage, we'll have to go back and like add those labels or whatever. Right. Yeah. You actually need right permission on most repos to be able to change the labels on. I just put what the proper metadata is in the, in the chat. It's fedora is the OS ID type. Yeah. So it's not F cause it should be fedora. Can't be fedora. What is that? So, in this pair programming exercise, someone needs to have the privilege to add labels to it kind of documentation. Okay. The only so. Yeah. And maybe somebody is that somebody was doing. Um, Vadim might be doing it. I haven't been doing it because I'm not that person. But what I'm going to see. So if we look at the issue, it should be logged. So look at the ones that were closed. And if you look at the history of those, it might, it should say label changed. Okay. Yeah. So first submit this one. And then that's, so it's there. So we can, we've got one submitted. And then let's see what's been closed with any issues that work. So I went to one that was closed and I'm looking at it now to see who Steven could, could now solve is the person who changed it. So the assignee is the person who actually labeled it. Okay. D on for this. Yeah. Steven, I'm sure Steve has increased permissions in that in that repository too. I have some, but I'm not sure I have that one. Yeah, I don't, I don't have any permissions to change labels and whatnot. They don't trust me that much. Sounds about right. So that, that's the kind of, so maybe if we assign them all to Michael Burke that we find, I know Mike, that's not going to make you thrilled. But can we, can we even create one? Can someone outside can create one and assign it to you? Then you'd, you'd get tasked with it. Yeah. At least I got notified of it. Yeah. And then you could figure out. Yeah, that can work. Okay. Yeah. So I think we caught enough here as long as we have the right section in the, in link, link to the section to our doc put that in. And that's probably enough to go on. And then we'll get Mustafa in there. And then maybe, maybe, I don't think he has privileges. He's only been with us for four months, maybe. So, I think that's, that's really what I wanted to know and see how it would work. And as long as you're okay to start with being the person tagged for that. And then if it gets outrageous, you can wave a flag of truce and we'll, we'll figure out something else. And then when you broke for Dean, now you're going to break me. Yeah, I'm going to try not to. We don't like to break docs people. Engineers, we're really good at breaking docs. Almost more important. Did I say that out loud? No. So, yeah. So that's what I'd like to do is, and I was hoping Mustafa would be here, but then we can pick once, pick a date and do this. And then what I wanted to do was have a hackathon or hack the docs section to, to do it because I think we're not, we'll see how far Bruce and Mustafa get, but there's a lot of docs in there. And then some docs that are outside of docs.okd.io that are in random things that we could also start cleaning up. So that's, that was my goal. But that's, yeah, that, that'll help a lot. And hopefully I can get them Bruce and Bruce, are you done with school now? Or is it still another week? Well, I'm, I'm pretty much done with school now. And we, we have a sort of meetings and departmental things and whatever, but that's ongoing for the next month. So for all practical purposes, my time is a lot freer. Okay, let me see if I can do a three way email. I'll CC Michael as well. Now that we know your last name, so that you're on the thread. And then what I'd like to do is have you guys, even if it's just an hour or two, spend together and I can host it again, or if we need to and do it maybe this Friday. And just walk through a whole bunch of them, see how much we can get done in an hour or two and find them all. And then log a bunch and see how it lands on Michael. Like, and once we have, you know, like 10 or 12 things in there that we found, which would be wonderful. I'm curious, Michael, when the next time they'll rep, these will get patched and revved. Is it every release that we rebuild? Yeah, yeah. Yeah, right after I merge the changes. It should show. Yeah. It will show eventually. Yeah, within hours. Okay. So it's not, it does not take long. Very cool. So that's the people who don't have the ability to label the issues they can assign. Let me try. How's that? Let me see if I'm going to, I'm going to steal the sharing here. Oh, please. Can you, let me see what I can do here. If, if we have the bot in there, you should be able to use slash assign, even if you don't have permissions to write there. So there should be a way for people to assign issues. Yeah, it doesn't, it doesn't let me do anything here. Don't know. I don't have privileges. But I can always do, like I could always put an at in the note. And that's how I've done it in the past. So that you get flagged. Okay, that would be. I think that since we can't assign, we can, you know, attention, do something like attention. Just want to bounce this off my program and project manager. Just make sure she's okay with it. Yeah. If we did something like that, since we can't, and then make a note. Okay, D. By the way, but yeah, that's, so that's, yeah. What's your GitHub ID, Diane? Is it part of that? That was part of that. D.Mueller 2001. That's what I got. She's very young. Very young. Yeah, very young. My Google account is very old. Let's put it that way. It's 20 years old now. All right. Slash of sign works though, because I just, I just assigned Diane to that other issue. So when did you got, now you got work to do Diane. I'm going to stop sharing. Show me what you did. Just so you're your screen. Just now I will. Now I will share. So this is the, this is the one we just created. And what I did was I typed a sign at D.Mueller and blah, blah, blah. And then it added you to the assignees up here. Oh, I didn't know that. So, right. Now I probably can't label it. Like there is, there is a slash label command, but I probably, it probably won't let me do that. Give it a shot. Try it. What's, what's another label here, I guess. Because it's already got okay, D.Mueller. I don't know if it would be. The kind slash documentation. Yeah, that's already on. Let me just see if there's another label. I could grab quickly. Those are all branch labels. I'll just try putting service message on there, even though that's not right. Yeah, you can see it doesn't, it has supported labels. So like someone could come in here. Doesn't seem like okay D is on the supported labels though. So if we could get okay D added to the supported label, like I could theoretically label this as platform AWS. Oh yeah, fine. Thank you for that. Yeah. Yeah. So there are people can do labels. We just don't, we just don't have one that's like, we don't have an okay D label that is publicly available. I doubt I can add like docs approved labels to this or anything. All right. Well, at least we can assign people to it. So we can assign Michael to them and myself. And that way between me and Michael, we can track them all down. So that's actually really cool. So that gets us to the next step. And then the other next step is getting Mustafa and Bruce together to do a section, pick a section. And maybe, maybe it's maybe not a section, but maybe it's to find all the our cause references to start with. That would be an easy task to do. And then we'll see how that percolates to the system Michael. And how much headache that causes for you. And you can tell us how much you love us and we'll still do it anyways. But that's, that's what I was thinking. So how about if we pause there and go back to Jamie, what you were talking about in the beginning, the community support landing page in okay D.io. Because I have one other question that I was going to bring to you is, I know at the last meeting, I said that I would go into the open shift dash devs and the open shift dash use user description at the top and put some verbiage in there that said, if you're using okay D go here. And I drew a complete blank at what that verbiage should be. And I figure this group might be able. So if you go into Slack, I certainly, I look like I had privileges to change that description for some strange reason. So I could do that and I will share my screen and see if start sharing if I can get there from here. Tell me if you can see my Slack. See my desktop, everybody else is seeing, somebody says something they shouldn't. So up here, I don't know if everybody else has it, but I have edit privileges here. Open shift dev and open shift user. And there is nothing, there is, I can add a topic and. Oh, I can edit it as well. I can edit the channel topic, yes. Looking for, okay D technical support, please. Check out the okay D working and then put in the link to the forum. I didn't want to do that on open shift dev, not open shift users though, right? Because open shift users is the OCP users. Well, it might, it's a mix of both. People show up in both places. So that's why I'm being explicit. If you're looking for okay D technical support, go here and I'm just going to grab the URL for that. And but that's what I was like, that was my worry was that I would be overstepping my Google. Don't worry, if you really overstep it, the Kubernetes Slack community admins will come find you. Oh, I know, they know who I am. If you're looking for okay D technical support, and maybe the community, something like that, you're looking, yeah, yeah. I'm just going to copy that and put it and go to dev. See, this one says community support. It's trying to, so that's why I was thinking, just put it in the users, because this is supposed to send them to the user's text. I don't like the split between the users and dev channel is odd to me, because I noticed people showing up in the dev channel asking user questions, and when you point out there's a user channel, they're like, I'm looking for developers. I don't want to be in the user channel. Right, yeah. I was like, are you kidding me? So I can just add this to it. If you're looking for okay D technical support, please check out, please, how about please also check out. So it's, and let's leave it at that, and then, oops, it's too long. Yeah, that's pretty long. Okay, give me a shorter version of that. Let's see, how about, oh yeah, let's see. Yeah, this is the great screen sharing game. The great, yeah. Okay, let's see. Yeah, if you take out all the, please, if you're doing this and just say, like, okay D technical support, blah. Or yeah, right, even take out the please out of that, right? It still needs the development chat. Yeah, you got to drop your Canadian niceties for a minute here. Tell people what to do, you know. Let me just see if that fits. Then do this, you know, I have been told that I've been turned into a, oops, controls it. That's right, you're not a native Kanucka, Stanny. I'm not a native Kanucker yet. Yeah, although you did say controls that, so you're getting close. I know, I did that once, minus five. Just take out working group and make a WG or a community led forum. It doesn't even have to be working group forum. It could just be, you know, I don't know. On this message, we probably don't have to say community led because you're just trying to get them to go somewhere. Right. And in the description of the forum, I think we can make sure it says something like community led. Right. Yeah, there we go. Yeah. Just on a set top. So what's the non, this part here is what's awkward here. Let's just set the topic and let it go for that and see if I get yelled at. We should review the Google group description because it says things like we'll also include discussion, which it does. So we'll also seems like a. See, I just took out that little phrase at the end there. And let's see if that works. Let's see if anybody notice. See the community led working group forum or edit, maybe visit. There we go. All right. I'm happy. I'm happy with that group thing was well done. So I wanted, I was thinking about something earlier when we switch topics and like, you know, so like we're kind of addressing one side of the issue here in terms of getting the information out, you know, where people should go for support, etc. But I was wondering and I was starting to think about this before when we were talking about, well, we need to get the red headers on the right page about doing the right thing in the community. But and so I was thinking, well, maybe we can gather the red headers to talk about this. But honestly, I wonder if we couldn't start making like maintainer guidelines for OKD, right? And then like once a quarter, we do like a maintainers meeting where people who are interested in being like a maintainer in the community, we could just explicitly say like here are guidelines for how we're going to interact with community members. Like if someone reaches out to you directly and tries to start a support case, like these are the things you should do so that we could help create like a community atmosphere where everyone's on the same page. You know, it's not just like, let's pull the red headers aside and tell them what to do or let's get the deem to do something different. Like let's just get the whole community together and say, look, if you're someone who loves OKD and you're participating in the community and you're like answering questions for people, you know, we as a community would like to make sure that no one's time is being used exclusively. You know, that everyone's having a good time. And so if you're that type of person who likes to answer those questions, here are some things you should be aware of that we as a community endorse. You know, we endorse your right to say, you know, please don't contact me, you should go to these forums. You know, we respect your right to say, no, I can't answer that question. You should go look at this. So just giving the community members tools so that they know exactly how they could brush off. They could, you know, it's totally okay to say, no, I don't want you emailing me like those kind of things. And then we can start to make it more of like, you know, a community atmosphere for how anyone should be able to interface with this community and kind of have those expectations. I think that's great. And I think that goes alongside the thing, which Vadim actually already started work on. Folks notice he posted in the channel, he's created like a how to start troubleshooting guide and he found some documentation that already exists and he started to create some new stuff. We need to solidify that on the site. And then so that same group that you're talking about, Mike, could be informed or informing and informing of that documentation, so that everyone's on the same page of, when we want to help folks, this is what we need from them. And this is what we need for folks to be able to help themselves, et cetera. So I think that would pair nicely with those meetings is for folks to talk about that aspect as well, because the maintainers and the people that are answering questions or whatever, they're going to notice trends that maybe the self-help documentation is going to need to incorporate or added things or added things to the frequently asked questions and whatnot. You know, so, yeah, I think that's a great idea. The other thing that is not explicitly clear or if it is, I missed the link to it, is the contribution ladder, like how to become a maintainer or how to become, how to get these other privileges. And because of the nature of OKD's sibling relationship to OpenShift, it's tricky. And so I think more language to describe the sibling relationship and not so much the why, a bit of the why, but where contribution can be made and how do we, so we're probably not going to give maintainer privileges on the OpenShift GitHub repo to someone outside of Red Hat at this point in time. I know I'd like to, I've been trying for eight years. So, and I would like to see that happen eventually, but how do we give people a contribution ladder and recognize people for their contributions, whether it's on docs or in technical support, answering questions or public speaking or workshops and demos and stuff. That's what goes on in my head, is that we have to figure out something to recognize people's efforts and to reward them and give them those hero badges and pats on the back. And I know I can't do it with t-shirts because I'm so great at getting t-shirts to people. But also, that actually also helps, Diane, just to point out that also helps in terms of knowing who to contact for particular things. Because once people have those descriptors, those labels, then you can say, okay, we need all of the people who are docs people. We need all of the, you know what I mean? It's easier to pull people together for various tasks. So it's, there's multiple things that are... So this is a very good, and I think we're at a healthy point with the community where we have enough people in each of these things. Like we had enough people to do different deployment tasks. So we had vSphere experts and we had, you know, the theoretical bare metal Libvert experts or, you know, all of them, home lab experts. So we're beginning to have these things. And I know Fedora has a concept of badgifying things, you know, where people get a badge because they're, you know, I've deployed my home lab. Bravo. And thank you. And, or I've found a bug in docs, you know, kind of badges. Totally. It may be time for something like that for at this point. It hasn't been in the past. But something I think would be nice to put in place. And I know I'm happy to do some research on that and come back and even ask maybe one of the Fedora team leads, you know, how they created their beautiful badges. Because I also want to reward people for sharing their use cases. You know, if Bruce, you do a .edu briefing or, you know, I've given... I've hosted five office hours, you know, or whatever. But something, think about it in terms of that. And I know that's not the same as the contributor ladder and getting maintainer privs. But I think the community is now at a tipping point where we're not the same 10 people. And we could be doing something pretty cool with that. And so that would be my hope that we could figure out something like that along the lines of being more explicit about where you go for support and then the reward for supporting people. Is you get a badge? I answered a question or, you know, whatever. If that resonates with you guys, I don't want to trivialize. No, it's funny. I was just writing those like exact same words down to Diane. Like, because I was thinking the same thing as you were thinking. And I was like, you know, what we should do is we should reach out to the Fedora community people and ask them some of these questions. Like, look, we want to kickstart our community to have some similar features as the Fedora community. And like, you know, like you're thought about the badges and whatnot, like that's amazing, you know? And it's like, I think we could learn a lot from them on the community level on like, how could we structure these things? And then also, yeah, if we could get some technology like badges and whatnot, that would be really cool for people. Yeah. But there's always the administrative side of it as well. So like, how much of it can we automate? Like someone like Mustafa does finds a dock bug. He gets the dock. He gets a little badge that has a book on it or a pen on it or something, you know, that it's automated. Like when it gets fixed or whatever. There's another side to automation too, though. Sorry to cut you off, but like, because I've been doing a lot of Fedora stuff over the years and I still get automated messages for packages that I've worked on and whatnot. So there's another side of this too, which is that if we start to build like OKD community maintainers and whatnot and people sign up for different areas, you know, we could very easily create automation that says like, Oh, a new issue has been created at OpenShift Docks with the OKD only label. And it blasts an email out to everybody who signed up for like docs emails or whatever, right? So we could build that automation. So I think the first step in all of this is to we have the sort of sign up sheet for the working group meetings. Maybe in that document have people select or write down as bullet points under their name areas that they're interested in. So or it, I should say and maybe at the top of your login document, Diane, have a list of the different categories and then just have people copy and paste into bullet points underneath their name what it is that they're interested in like their particular area of participation. Because that sort of forms the foundation of all of this is finding out what it is that people really want to do. And do we have we have a lot of people who are members of the working group that are showing up for meetings, you know, 17 sometimes, etc. But what do they really want to do and who really wants to work on docs, who really wants to be called. Vadim actually pointed out that a couple of issues that came in in the past couple of days are ones that are right for people who actually want to start dealing with maintenance of the code base and troubleshooting of the code base. It would be good to know who the people are in the working group that actually have an interest in that as opposed to him just sort of throwing something out and whatever because then once you have a sense of who wants to do what you can create guides or templates or whatever for the for each one of those things. If you're a if you want to be a maintainer here's some things to know you want to be a docs person here's some things to know right now we don't have a doc of docs. We don't have a doc that outlines where are all the docs and how are they maintained who has access etc. People who want to get involved with docs it'd be nice to be able to just point them to something that says okay here this is the lay of the land moving forward. This is how you can participate etc. And then for each of those categories. So yes, all of that is good. So with it on the doc side of stuff my my initial foray is to get to figure out the workflow for updating docs.ok.d.io. I thought that was a tangible simple thing to do but I do think an overall audit of all the docs that are out there around okd is something that we need to take on this little group needs to take on and do. And then then from that that's maybe how we structure the review of the hackathon the hack the docs is like okay here are the guides they're still not over on okd.io yet. You know let's you know what is this this chunk needs to belong over here. This chunk needs we need a community support page. And in the hackathon someone can work on that and come up with a verbiage for that. You know we need better more explicit directions on the blog. You know something like that I mean whatever it is but that audit I think is probably our next big task of this little bunch of folks beyond figuring out the pair programming pair review stuff. But I think if we do those two things in parallel we could have a mid-summer hackathon hack the docs for okd to kick off that and then we still then the two tasks that Vadim has can help kick off the conversation about who wants to be maintaining the core stuff and reviewing that. All right. We're at almost time so we should probably wrap up any last minute things. Last minute thoughts. I was just going to say like I like the talk you're putting down Jamie about like kind of this being a foundational exercise in some ways because like you know my my long tail dream you know like if we heard Diane's dream in some ways my long tail dream is I can't wait to see the day that we have okd community members contributing code updates that are making it all the way into the projects that we have that build up okd and like for me that would be amazing because like watching all the vSphere work that's happening in the community and knowing the kind of troubles we have with vSphere behind the you know the walled garden as it were like I want to see that become a reality and I think it'd be really cool to see. We might want to do another push to get a few more people in the docs group because then we've got Joseph is usually here and I think that's about it is it's sort of been the four of us or so or so five of us. What mystified usually comes but I think he's off this week for some reason I think he might have gotten because it's a short week people a lot of people took vacation this week and I know yeah I know a lot of people have taken this week off.