 Well, let's get started with the documents meeting. I put a link to the agenda in the chat and go ahead and put your name in the attendance there. And this is our meeting for September 7th, 2021. And take a look at the agenda real quick. And since Diane is here, there's a couple of items that were sort of hinged on Diane. From the last time that are there. Yeah, so take a look at real quick. If there's anything you want to add to the agenda or remove from the agenda. Let me know now before we delve into everything. I was going to add in a note I have and I think I told Brian. I'm not Brian Bruce about it is it Bruce it's Brian in this. Sorry. There's too many bees here today. Sorry about that guys. I have a resource that we can apply to cleaning up the GitHub pages and making them look a little more beautiful from that I use for the common site. So, we'll add that into the mix today too. And then I was going to invite him to come to these meetings. Excellent. All right. Well, let's jump into what we have here. The, and this actually I had skipped from last time we take skip out. We can be here since Diane us here. So Charter update and questions. I was not around for the Charter creation process of Diane. These are more questions for you. When we look at the Charter. Um, there's some hold on. Let me see if I can pull it out to share the URL and put it up on the screen. So, yeah, let me pull it up right here. So. It was a long time ago. Yeah. And that's under the community. Uh, one. So, let me a couple of the manipulations here. They're in my screen in okay. Great. So, if we look at the Charter, this was done last done in 2019. And there's references here to CNCF stuff. And there's also, so my 1st question, I guess, is in regards to the CNCF stuff, it seems like this could be rewritten in a better way. So, do we want to actually take a stab in the coming weeks at sort of rewriting this a little bit? Cause it looks like there were some ideas that were tacked on. Like this sentence here seems like it was sort of tacked on at the end as an afterthought. Well, just originally, it went through. So, so let's go back to the origins of okay D just for a second. So, you know, there's a couple of things as 1 is we did not push open shift into this as a CNCF project because in the early days. This origin was something separate and then it morphed into a Kubernetes thing, which was a CNCF project, which is why the reference here is to that. So, some CNCF reference should be in here because we are related to a CNCF project, aka Kubernetes and a bazillion other things that the CNCF has under its umbrella now. I think what I'm going to provide guidance and coordination for CNCF project. I think the above paragraph, the CNCF projects working within the SIG scope. I think what we did, we must have lifted this paragraph from a CNCF governance document and we should change that to maybe some projects. Just the word sub dash projects within the working groups scope, because I think we started out as a SIG and it never got updated. So I'm perfectly okay with if you want to make today, like just work to change that first paragraph and make a create an issue for it and bring it to next week meeting to make that correction. And take out the CNCF reference in that 1st 1, I think that's totally fair game. I think the 1, the 2nd line is, is there Just because there are so many engineers working in CNCF projects and Fedora projects and Red Hat projects to clarify that. So I would leave that in there. That, that to me actually resonates or what we're trying to clarify here. So people don't come here and mistakenly think okay D is SIG or sub distribution or some things related to the CNCF. So for me, it clarifies something that You know, for wandering pools who come in and land on this page and might think we are part of this CNCF because we have things like K3 and, you know, other some projects. So that's kind of important. I think one thing I think we might want to do is to And I'll give it a stab sometime in the next couple days rework that paragraph so that it reads something along the line, although the OKD working group is independent of both Fedora and the cloud native computing foundation dot dot dot. And then sort of inventing phase into that 2nd paragraph stuff so that we're sort of flip it so that it's sort of a although we are independent. We provide this and blah, blah, blah, blah, blah, is that makes sense. Yeah, it make the proposal make log an issue just just do it and we can hash it out. I, you know, I think if we change it to change that we definitely need to change the word SIG to working group. And we definitely need to take CNCF projects and change it to sub to projects, you know, sub projects or something like that like this docs docs group is a sub initiative of the OKD working group. The other thing is did we ever land on an official Word or words to describe the relationship to OCP. There's been several floating around there was sister there was it's not upstream. So what do we what do we want to say and I think that this should be I think I think what we did was a sibling sibling. Yeah, we're sort of trying to work towards getting to upstream someday, maybe, but I noticed that 4.8 is actually out. Yeah, we were. I remember Vadim and Christian mentioning that it was going to be soon and that it would be 4.8 would be the turning point. But I think actually that didn't happen. Yeah, no, unless they contradict me, I don't think that's that's happening. We originally were the upstream for OCP back in the day and then when we switched over to Kubernetes, Kubernetes became the upstream and we became a sibling. And I think sibling stream is the best way to describe it. You know, other or a sibling stream. Yeah, does that work for everybody else in the meeting here? I want to make sure everyone feels included in that. Well, it makes it makes sense. I guess then the question is if everything that the red hat does is in quotes open source close in quotes. Therefore, OCP is as well. Then on paper doesn't make sense to say that we are the open source version. And then it becomes more confusing about exactly what is the relationship. Well, there's sort of a branding issue. I know, but yeah, that's what I was going to bring up right now. Open shift is no longer. Yeah, no longer one thing. Right. And even as a product, even OCP, then there's OKE and there's a bazillion different met, you know, managed service things. And yeah, so what's open source about origin, which is what's in the origin repo is what we are the sibling stream of. So, you know, the only thing that and the thing that the code that in I'm trying to figure out how to word this best because it's words with the origins code runs on rel. Right. So you, you need an open source or you need an operating system that's open source to make a true open source distribution of open shift. And that's what OKD is. So it's not confusing. Yeah, I'm not confusing. No, no, no, no. It's only taken me eight years to get it out that way. But it is really, it is. I think the more interesting thing about this distribution is its relationship to Fedora CoroS. And that's what makes a true open source distribution of, you know, because otherwise you're constrained to rel and if someday they came out come out with a rel that's licensed in a way that could be open source. Then that then what Bruce what you were describing. Yeah, the code may or that's in the origin repo maybe open source, but the thing that it runs that it's required one of the other required pieces components isn't yet. Okay, so that's that was a can of worms question, but I think it provided at least a little bit of clarity on what we should put into this. I mean, the word upstream is, I guess is, well, since version four, it's never been true. Yeah, absolutely. Yeah. So in what we use internally to describe this and there are other projects that are similar to this that are that have a sibling stream approach as well. And I think you're going to see ACM and OCM advanced cluster management and open cluster management have some semblance of a similar thing. Going on, but we'll we'll see how that all plays out to another thing that caught my attention in this was the little statement that says things that are out of scope would be initiation of new open source projects. Do you have any sense of what the history of that item is just for my eyeballs highlight that line on your screen. There you go. Yeah, so I think we would not be, for example, kicking off as an OKD working group, our own version of say a monitoring project like Prometheus or that that what we're trying to do in this working group is work on OKD and the OKD bits and parts. That's, you know, that was and I think that comes also from some guidance we got from the CNCF reviewing what the CNCF was doing and what some of the other projects were doing to is that we really wanted this group to focus on that just OKD. So just picking up on that time. If we go and create a OKD operator project, is that not new open source project? Well, operators is a nice new can of worms and it has its own community. And I think what we talked about at the last working group meeting and I tried to get Austin McDonald, who's come should be back for our next working group meeting to come and talk about how to get it how to build a better relationship with the operator framework community, which is a CNCF project, which is where if we were going to do something operator ish, we should work with them or be a sub project of that community. And so that actually would be out of scope. I mean, we might be able to kick off a discussion group or a working group around it. But if we were going to kick off, you know, OKD operator framework or, you know, that sort of thing like that change the technology that is in the operator framework or expanded upon it. Then we would go. This is my opinion. I have lots of them. We all have them that we should go and work in the operator framework to do that work. Like, you know, sometimes you'll see rancher and the K3S folks go and work in the Kubernetes place to get an extension to make something work with rancher. Those those kinds of things that that would be my clarification for it. And so for me, and this is for me because I think I was around definitely when this was being written and copied and pasted from other places. That line still rings true. And because we are so closely tied at the hip to OCP as a sibling stream. It's this difficult dynamic where we even inside of Red Hat push our people to contribute further upstream if they need something to get into open shift, like go put it and put make it available to everybody, every Kubernetes or every operator framework person, rather than put it just an open shift. And because just an open shift means so much more than just putting in creating open source project. And that probably didn't help at all. But hey, yeah, but I think there it's again complicated, I think because there's a whole pile of operators that we have on a issue in OKD that we've been talking about for a long time. And it's many of these operators on the OCP side seem to be part of open shift, like serverless, for instance, is one that keeps coming up and came up with a through my email this morning. And it looks like it's sort of at this point, practically trivial to get it onto quay. And it's sort of been that way for many months. It looks like going through the the issue. But it still hasn't happened. So that so to me that is not a new project. But is it a project that's an OKD project? Or is it a serverless team project or serverless project? Well, if you can get them to do it, more power to you. Yeah, so but I think there's another issue here. So there's the individual operators. And where possible, they should be in the community hub rather than any special one. But there are a certain number of operators, which as Bruce said, are quite tied to the OCP product, pipelines, gate ops, things that are in the registry dot red hats sort of repo. And then to make them appear, we need another OLM catalog, which would be an OKD project that we possibly wouldn't want to give to the operator framework team. It's going to be the OKD catalog that replaces the red hat catalog in OCP. So I think that there's a distinction here that I have in my head between an artifact like a container or a catalog specific to our community or our ecosystem versus a full on project. Okay, so that's that's that's, I think, what when initiation of a new open source thing. So if we have to create an artifact, such as a catalog or a container or an image, or and we have to work with other people and coerce them into building it for us and maintaining it. That's a different ball of wax than initiating a new open source project. Yeah, I guess it's, I guess it's equivalent to Vadim's install a repo. It's something that he had to do to make OKD work, but it's an asset in the OKD project rather than a separate project. And there's a reason they call it artifact hub in the CNCF because they're getting and at first I was completely resistant to that. I wanted it to be operator hub, you know, because everything should be enough. But then once they kind of explained it to me a little bit like the thick skull I have. The idea of artifacts versus simply operators operators are artifacts and there's helm charts are artifacts and those things are artifacts. But this line that he's got highlighted here initiation of a new open source project is different to me. So, yeah. So that that's just around that one line, but I and what it means to me is that there's this a log jam around collaboration and build processes of those artifacts, which is what I'm trying to get the I think I said in the last working group meeting is trying to find a person from the operator framework group to either come or tell us where to go, not where to go, but where to go. Which meeting to go to to get this work on log jammed together and I've asked Austin with Donald to come. Think he's done with his class on the 10th, which I'm not sure that so he should be able to come next to the next working group meeting. So I guess what I'm taking from this is the content of this current document. If we don't understand it and we've been part of the community for a while, but it suggests that it does need wordsmithing to add clarity around the finer points that we've just discussed here. So we do need to sort of make sure that it's from somebody new. It actually reads and they can understand the final nuances of what what the doctor means. Yeah, and I agree with that Brian I think that one of and the reason I brought this up was as okay D becomes more solidified and there's some things I'll be talking about towards that I'll be bringing to the group towards the end of the meeting. That there's more of an interest, there's an increasing interest in making okay D more stable and better documented. And as that happens, the charter and the processes are going to become more and more official and real, as opposed to things were kind of wavy in the beginning and whatnot. So I think it would be good to revisit this. It sounds like folks have interest so we can work at updating this and then seeing if that aligns with process and see if process needs to change with the larger group. So an example of that is this, this says here about membership that membership is actually determined by putting in a a issue and saying that you're a member. And then that gets recorded in the members md file. We've not done that for as long as I've been part of the group. No one's actually done that. And so modified for two years. Right, exactly. So I think the question will have to come to the group with some larger questions on this, even before we modify the document is, do we want to still follow this process? And if so, then we need to vote, or we need to start doing that process, or the larger group needs to vote to say no, actually we want to change the charter, because this process is too onerous or there's a better way or something like that. And that that I think that's the first stuff editing out the CNCF and the sig words that I think we can do in a quick issue and get that through whether or not we want to go to this membership dot members dot md format and start using this because we don't really currently vote on anything. We haven't. And I think you're right. We've hit a maturity level and an adoption level of OKD out there in the world where we may want to do this. We may, you know, we may decide, you know, there's something we need to do that that requires a vote beyond, you know, consensus in the meeting. We had, we, we are close to that, I think, I think we're close to that. So it's not a bad time to revisit it. And if so, then get everybody to do this that considers themselves an active member. And that would be not a bad thing. All right. Well, then I'll add it to the agenda of the main meeting for next week, just a little bit of time to introduce this issue and see what the main group thinks. And anyone else that's that's on this call, I'll take a stab at some of the stuff up towards the top here. If anyone else wants to as well. Yeah, I would, I would ask you to keep it as simple as change is possible, you know, because this did go through a legal review. And I'm hesitant to ask Red Hat Legal to do much more than look at it again quickly because that takes time. All right. Okay, before we move on, is it worth having a separate repo for five documents? Or should this be merged into the OCD main repo or? I think it's having it separate. That's an interesting point because we've got the community, which is the, the working group stuff and actually the meeting notes. Maybe it makes sense for the meeting because we talked about, oh, the meeting notes are in the HackMD, but they could be in the OCD.io or they could be in the community one. It is kind of distributed. Yeah. Yeah, I am not an expert on documentation or where things should go. This is probably pretty apparent. The hesitation I have about moving this out from the OpenShift repo itself is that the OCD one, the OCD.io repo where we're going to go on to the next topic here that we've now got that is in a weird wonky repo directory too. It's OpenShift-cs, which actually stands for customer success. It was the team that, the website team that worked on it with me and created it ages and ages ago used to be called the customer success team. And now they've been changed their names 10 times since then. So I think it's more likely that the OCD something has to give, you know, and it's a bigger conversation about where. A solution might be to rename this to be the OCD.io in OpenShift community and to archive the one in OpenShift-cs. I think that would be my druthers, but then becomes the other problem of permissions to do anything because then the OpenShift repo basically is 99.9% Red Hat engineers. Who have permission to do anything. There might be a few non-Red Hatters who are associated like with Fedora and Linux that might have permission. I don't even know, but I would say. So that's the other thing. So it's freedom versus respect, maybe. How's that? That brings up an interesting point though. So if we wanted to do the agenda items and have the chairs be able to modify the members file, wouldn't the chairs all have to have? Yeah, I don't know. Well, I guess they could submit pull requests to the community repo. But for me working on the agenda, I wouldn't want to submit a pull request and work on the, so either I would need access or me being representative of anyone who's not part of Red Hat. Those chairs would have to have access to that repo to the community repo. So I think the bigger, I'd like to have a conversation about that with Vadim in there because he is sort of our liaison to the engineers who have the privileges to do all of that. And that could be the next working group meeting and add that into the agenda about how can we, this rag tag bunch of repos, how can we make them into a more respectable and still have the ability to edit and do what we need to create a site underneath this. Yeah, because, because, because I guess we want to consolidate where we can. I mean, but also like bring Vadim's installer from his personal GitHub into an open shift and okay D repo. So yeah, it sounds like we do need a discussion around our use of GitHub, which will come into all the permissions and ease of use and but I think it's worth just trying to remove. I mean, I don't see a point of having a repo with five documents in where we can have a document repo somewhere else where everything's kept together so. And maybe the answer is just to move all this under okay D dot IO and get move okay D dot IO out from open shift dash CS into its own GitHub tree of things at this juncture and then that would be. Yeah, and I like that idea that that one sort of resonates with me. Okay, so I don't we're at halfway through the meeting. I do want to get to the other things. So I've added repo discussion added to the main meeting agenda. Yeah, beta site. Brian, do you want to give us an update? I think you were waiting for Diane to push some buttons. Oh, okay. Diane actually gave me permission. So I pushed the button myself, but I actually put the link in. So if you just click that link. And let's take a look. And this is the repo that that Brandon, I'm hoping will be able to help us make pretty. Right. So the first thing you've noticed, I have totally removed all of the middle man. I've totally removed bootstrap. This is a pure. Markdown site. So everything about okay D banner is now comes from Markdown. So we can go and change the homepage. We can change all the documents or just markdown now in a git repo. And if you go to the very little top to the left of the search. And you'll see a little toggle switch. So we've got light and dark mode and depending on the browser, it should automatically pick up your systems preferences and just switch automatically. If you shrink it down. So if you just move the browser to the just shrink it leftwards, it is fully responsive. So it can be used on a mobile. If you just keep going, just keep going more and smaller. Just imagine it's like a mobile phone size thing. You'll find that the sidebars vanish and then you would get a hamburger menu and it just sort of it's all responsive. So I think this is now a point that if people agree that they like this, we need to get people to test it play with it. You notice I did move the menus from the top to the left because I found that getting around the place required two clicks. Now we can just expand the section. So if you're looking for stuff, you can just go and expand the section trying to work out where stuff is. So my next point is to now populate it with primarily what's on the original site. So the question, do we want a landing place for documentation? I'm not happy that we just jump out of the site and sort of abandon the OKD site to go into documentation. I'm just wondering, do we need sort of a landing site with a link to the documentation rather than just busting out? Click on documentation again. Just show me quickly what it does when it goes there. I mean, I'm OK with it going to that other site because it means that Michael Burke keeps maintaining it. The guy is not on video right now, mostly because it's something that's generated. Oh yeah, I'm not saying move that content here, but I'm just saying, do we want a page that then gives you the option that this is going to the documentation site? Or documentation landing page? Yeah, go for it. Yeah, that would probably be good. So yeah, I think you're right about that. Yes, I'd agree with that. And the other question I have is these things that say temp content community etiquette, is there stuff to grab and put in there or do we need to create that? Well, we were going to, you were going to look up Diane the rights and responsibilities type stuff from other communities. Okay, that's on Diane. All right. Yeah, that was because I think the gist was that we wanted to get something that is, you know, like the CNCF has has a nice guidelines basically in code of conduct and whatnot. And I think that having something there would be good. But I mean, we can search out stuff, but you had volunteered if you're strapped for time, we can. I would actually add a code of conduct under help or somewhere community etiquette and then just we'll grab a code of conduct and put it in there. But yeah. The other thing that we had from last week, which was we were going to ask for you is do we need any legal notices copyright license? I know there's some other open source sites. Have that in the footer. I didn't know whether we had any legal requirements or we wanted to go to the okay, the existing okay, the site for a second. There wasn't anything on there either. Yeah, I don't think so. I don't want to make it anymore. And then go to the very bottom. The only thing I did it. Yeah, I took out that powered by open shift because we're powered by get up now. Yeah. Well, I tell you the minute corporates corporate branding sees that logo at the bottom. They're going to yell at me anyways, because it's out of date and open shift online. I don't even think is a branded thing anymore. It's now. No, I think you're okay the way it is. I actually like the way it looks. So the missing pieces that you need me to do is how to ask for help community etiquette. Let's walk through it from the top. What's what do you need to pull over still Brian? Yeah, I mean, there's a lot of stuff. I mean, I was really focusing on the styling and getting the CSS right. So I've not really been looking at the content. I've just started moving the guides across. I haven't actually pushed it yet. So I've just started moving the guides, which is under the getting started. We've talked about moving the content from OK D main repo. There's that big read me there, which has a lot of stuff in it. So some of that stuff will come into the installation. And I believe we want to talk to Vadim in terms of what he thinks should be in this section. And because he created that initial thing and blogs or more or less I've moved across with there. Then it's the community stuff and it's the community contribution stuff, which a lot of it. I think we're going to have to create from fresh. I want to put a section in about how to update the documentation so people know how to actually use MK docs and make it really easy to get people to do that stuff for next week. I would focus on that so that everybody gets to see it. But I think if we run this by it looks great. Thank you for it. First and foremost, is there anything then if we get any styling or CSS issues that you can't handle or you don't have time to handle? That's what I think the third party contractor I have. I'm not a web front end developer. So they want to come in and do it properly. I think you've done a very good job, to be quite honest. What I would say is let's show it to the larger group next week, get their feedback. If they say, oh, that's ugly or that doesn't work or that's not working for them on their browser or something. Let's let the third Brandon work on those issues for us. We can even tag him. He's got a luminous coder. You'll see him in the OK D repo and or maybe other repos every once in a while. So he could he could do those things. But I think the stuff where we have to create the content, he doesn't know enough about who we are and what we're doing to do that other than maybe a grammar check checker. And I think one thing we can do is Vadim hasn't been able to show up to the last two main meetings at the next main meeting. If he's there, we can talk to him about splitting that stuff off of the OK D repo. Read me and some of which will go into installation, some of which will go into night, you know, nightlies, whatever we want to call the, you know, the stuff related to the nightlies for four eight and whatever. So, yeah, I think the larger group and also seeing if we can pin down Vadim to really give us his perspective on sort of breaking up the the installation instructions and stuff that's in that. OK, do you read? But I mean, I said, once we've got the instructions there, the idea is then that this should become a very dynamic site. Everyone should just be able to add content quickly. And even if you just want to put something on the heading that don't install four eight one because it's bussed this week and then next week when we fix it, we can take the thing off the homepage. We can do things like that very, very dynamically. It's not difficult to do so. Excellent. All right. Is there anything else on that before we move on? We got a handful of other things to get to. So there really is. So we're saying there's really nothing in terms of like copyright or anything like that that needs to be added to it. If so, then we can just strike that and not worry about it. OK, so delineation of resources for the working group and OK to users. We need to change that text at the top and give that to Diane. So we've been kind of putting that off as we worked on other things, but I will work diligently on that if anyone else wants to chip in. I will do it as a as a document. Maybe in the okd.io repo or something like that. And then this will be the text we put at the top of the Google chat group that makes it clear that that's more for working group business and then also change the text in the Slack channels to point to, hey, create a discussion item. And, you know, we mentioned this last time Vadim has really been doing a great job of. Transitioning stuff to the discussion items that really aren't bugs. They're not issues. They're discussion items because it's someone needs to know how to do something or something like that. And I think we're narrowing in on a very efficient process. Yeah. And yeah, this is that item Diane for look into the working group guidelines and conflict resolution. Yeah, now that you have, if you get Brian, if you get the mk docs documentation in, I will grab those things and I will try by next Tuesday to get that in so that people can see it and we can look at it as a group as well. See if that works for folks. And Bruce, I heard you, you start to say something good. Yeah, and I was just thinking that something that I didn't see in our process that might be useful is with respect to docs. Okay, which is that. Whenever, in theory, whenever there is some confused user that had to put in a discussion to get themselves out. Then the doc should be adjusted so that they wouldn't have been confused. And that sort of analogous to the philosophy that whenever you find a bug manually you put in an automated test. So that you don't get a regression. Yeah, and I've been kind of doing that summit. You'll notice some of the things that pop up in the agenda are things related on like repeated questions. And so it like at the main meeting I'm going to bring up the topic of single node clusters and also bear metal because we're getting a lot of requests in terms of documentation and in terms of issues in regards to both of those. And I think we need to flesh those out because a significant number of okay to users are looking for homelab single node cluster, you know, and sort of the minimal installs and bear metal right and stuff like that. So we need to up our game in terms of documentation because we're getting a lot of questions and a lot of issues that are based on sort of lack of documentation and some things that have not been tested. In theory the single no stuff should be easier with 4.8. It is but I don't know if you caught that discussion of the past couple days. Vadim was under the so when our FAQ, it says that you can do a single no cluster by just setting in the install config. The number of control plane, the one and the number of compute to zero. That actually doesn't work in 47 not in 47. Right and no one really knew that because it hadn't actually been tested and someone brought it up as an issue. Vadim actually I thought it was clear because like certainly in all of Charles single node installs that he's been doing for the last year. You have to hack a bunch of things. Right and that's it dawned on me like well yeah why are we why is Charo having to do that. And when there's this it hasn't been tested and sure enough that's the issue so it does work with eight I tried it actually earlier today and last night. So it works on for five. It does not work on for six or four seven. It does work on for eight. So we'll need to update the docs on that and up and up our game in terms of testing to catch those cases. Yeah well it's actually a feature in for eight. Right. I'm surprised I never tried it on for five because I don't think it was a feature then. It wasn't a feature and that was actually something for OCP that was touted as a feature was single node clusters right. But yeah back to your original point yes I think each I think it's an iterative process that each time we come across something. And folks should if I don't catch it if there's like something in the chat or email or you hear it someplace else that we're lacking in documentation or we're lacking in testing of something. Like please bring it to our attention so that we can add that in as a test as a as an improvement. Well it's tricky because you get hidden assumptions. Right. Like I sort of assumed that everybody knew this thing that that I originally learned a long time ago from Charles and I'm wrong. Right. Exactly. And that happens to me a lot of times in reverse. So yeah and I appreciate that about you Bruce. You've brought some things to people's attention over the you know past year or two that's been like well this is supposed to work and it's not or you know it says here in the documents you know and that's been really helpful. Okay so we're punting again on name and scope of the installation doc because Vadim wasn't at the last meeting I'll put it on the agenda again for the next meeting. The inclusive language update Brian you're sort of hinging on the folks that. Yeah so I have a little update on that I don't know if Brian, if you've gotten any feedback from them. I think we close that ticket. Yeah. That goes away when we switch to mk docs we have to rename the master branch to main when we do that switch over. I'm making sure that all the content that's in there is appropriate. So once we do the switch over, we rename the master branch. We set the CNAME tag redirect it and then that ticket goes away. Yeah, I think that. Thank you for summing up. And the other thing is I know that will Yuri's in on European time will Gordon just went on PTO, but Yuri is waiting for us just to say when we want to repoint the site over to that. It's just a DNS name change. So as soon as we get our content in there and group approval. We can make that happen and it, you know, whatever it takes 48 hours once that the full over goes and the sooner the better in my humble opinion. So, and that's why getting if we need Brandon to give you a hand Brian. Just ping me and chat and we'll make this okay the middle man thing go away. Very far away. The one thing it should probably be pointing out for folks that are watching this is that when we say that the ticket will be closed that doesn't mean that we're going to stop. At least that the documents group isn't going to stop like continuously scanning docs for things that need to be made inclusive. And we're not going to, you know, in fact, this came up. I think in what we put at the top of the Google discussion group and at the top of the slack may want to reference the code of conduct. Flash community guidelines stuff and have a reference in there to the inclusive language because I am noticing in the chat. There's a lot of hi guys, hi guys, hi guys. And although there's the CNCF has that bot that like says maybe you know, it would be better to actually have something ahead of time not after the fact. Yeah. Yeah. So I don't want anyone to get the impression that we're just going to be done with it after this. It's some it's an ongoing process right to use to make sure docs are up to that standard. Create build doc outline for Vadim. This is going to be Brian and I, we're going to hold off until the beta site is ready until Vadim can attend a meeting and we can and and Vadim has time he's incredibly pressed for time right now. And so we have to. I think Brian and I will do most of the work and then just run it by Vadim. The upgrade path notations Bruce that was yours. That was a discussion last time. Yeah. And I remember that was referencing. So the idea was that we would actually flesh out upgrade pads because there was you did find some documentation. On upgrade paths and and could we turn that into a like a table or something and can we better understand what red hat meant. And it was partially just defining what the notations meant. But there are some related things like some things that have come up recently is that. And. Okay, there's, there's, there's basically three places where a version of F cost comes into play. And at least like the way I built things on vSphere. I start off with a version of F cost that's in a. Where the ISO is mounted to, to initially boot the host with. And then that one pulls down a version that's referenced. In, in the. The initial ignition sequence. And then that. Assuming that boot and everything bootstrap and everything makes it up, then it pivots to a current version. Right, but actually interestingly enough, the team. Last week in a conversation was said to someone, well, we're not really using a version anymore. Because it gets modified. And it's a rebuild, basically of the month. So it's interesting for folks that don't know the way the in the OKD installer works. It actually downloads a version. Of it, you started with your additional version of F cost, which is. Downloaded directly if you're using IPI or you have to manually provide, if you're doing up. That gets booted into then a new version of F cost gets created. With tweaks for OKD and then it boots into that version. And then there's more stuff that gets installed on top of that. Right. So, yeah. And so it's not even. The documentation needs to be clearer about what you're starting with and what you're going to end up with. Because the question that sparked the team. To respond was that someone asked like, well, when I do the OS RPM tree. Command to look at the version. It doesn't jive with what. Is it is it version that's out there like available for downloading. You know, in the end. Right. Well, in the end, right. In the end, it's a referencing some machine config something or other. But along the ways, depending on which versions you get, some of them don't work. Right. And there's a variety of things that can happen. Like when you when you go from. One major release. Like 32 to 33 to 34 to 35, whatever. Then you can get into things where the keys don't work. So, so when it downloads it, they can't confirm it because it's, you know, they've updated the keys. And just down, downgraded, haven't we, because we have so many issues with networking. I believe I went back back a level. Right. Network manager. Yeah. Yep. Gotta love the, yeah. So there's so in instances where. Now, I think, I think that those things are made into the frequently asked questions of, hey, this version of F cost doesn't work for these versions of OK D. Right. So slowly, slowly, we seem to be improving those sorts of things. It might not. That sort of stuff that would be useful in the installation information information or a given release is what things you have to use when it. Yes. Yes. Absolutely. So this is a question to Michael. Is there any way we could get. A versioned set of documents for OK D like they do for OCP because we only ever get the latest. Anybody's currently on an earlier version. We couldn't put that information in. Good point. Like, are you still around. He's on the stream. He's there. Yeah. He's here. He doesn't have an answer. I'm asking different. Yeah, so like, if you go to like between 4, 7 and 4, 8 or, you know, can there be different, you know, minor version. Document loads. You don't see why not. We did that for 3. Yeah, so he did version for 3. Right. Yeah, because if you look at the list, we've got all the 3s, then we certainly just yeah. Can you look into that for us and generate that that would be pretty bloody awesome. And that would, but yeah, then we'd have to review them too. But also isn't it time that we remove some of the 3s because they're no longer. I would like to grandfather some of them or grand, grand, grandparent some of them. I think, but I don't think red hat supports any of them. At this point, no, there's in the wild. That's the problem. Right there. Michael is is 311 still documented anywhere for OCP. Yes, there's still supporting. Yeah, I've just looked at the list. We go back as far as 1.2. We could take some of them out. What is on the list Michael for OpenShift? How far back do they go for OpenShift? The question. For a minute. It was back to 3.0. Yeah, so if we could make maybe what we need to do is send a notice to the first find out. If you can add more variations on 4.x. And then do a notice to the mailing list saying, okay, we're going to grandfather the documentation prior to 3.0. We're going to stay in line with whatever OpenShift has for documentation. Otherwise use the way back machine. And, and then clean it up. Just do a notice and that from the OKD working group docs and socialize it at the next these ideas at the next working group meeting next week. Jamie will do and say that this is our intention is to do this and if anyone has any objections. Let us know. And Michael just to just to sorry, Diane, I didn't mean to cut you off. Go ahead. Michael, just to get a sense. Do we have the so right now the way things work is you're generating with a script. The OKD docs off of the OCP docs and just changing the names out. We put in a ticket for like a minor tweak here or there. Can we actually put in a ticket for like a new page to be created? Or anything like that or is it or are we just being limited to tweaks of what gets generated? Definitely a new page. OK. Tire books. Sam was inside of a book. Don't tell them that. That's a new project right there. An OKD book. No, it's an artifact. All right. Actually, you know, there are a number of books out there that are, I don't know could be OKD books. Yes, that are sort of, you know, like free for download red hat. Oh, PDFs or buy it from O'Reilly or whatever. Those I don't think it's been updated. What's what's that Michael? I'm sorry by books. I mean, if you look at the doc start OKD.io site. Everything in that table contents on the left side. What's new architecture installing. We call those books. Selective version. Yeah, look at that. These are all books, right? Because these are all separately accessed. Right. Exactly. Anybody wants to write an OKD O'Reilly book. Let me know. And if you have that much time on your hands. Don't tempt me. I'd be totally game to get into that with you, but I think that's another whole life. Yes. I want to close out. We've got one minute left. Just so folks know. We were approached by the red hat team. That's basically building off of a Kuvert for the virtualization stuff in OCP. And they want it to work better on OKD. So we will be talking at the main meeting about this next week. But if this is going to come into play in terms of documentation, making sure that we promote and encourage and test documentation relating to using Kuvert for virtualization on OKD. So just wanted to throw that out there real quick. Does anyone else have any last minute things before we sign off? We have one minute left. Can you read the outreach to the mailing list about pruning the older versions? Whose action item is that? That's mine. I'll go ahead and take that. Okay. What I would say about that is, Michael Burke, if you can let us know that it is posted officially that it is possible to add the 4.x. Version. I will do that. Then send the email out. We'll do Michael and I will. All right. We are at time. Thank you so much, folks. And I appreciate all of your hard work. See you next time. All right. Thanks, Brian. Take care. Big time.