 The working group documentation subgroup meeting for July 12th and we have an agenda that is a little bit light, but go ahead and take a look at it. I'll give folks a couple seconds to see if there's anything you want to add or change. Brian, maybe if you want to cover the meeting from earlier today, maybe just put a little blurb. I was going to cover that within the governance and process that also is going to cover like the community project side of things that we're kicking off. All right, are we good to go then? I think we'll go ahead and jump in with it. So first item is technical documentation. There's no updates. Jack said it would take him a while to work on the blog post that he'd chip away at throughout the summer. Glenn Marcy has been furiously working away in the channel. I noticed he was commenting on his SNO triumphs and tribulations as he goes, but he's definitely chipping away at SNO documentation for us and getting successful, working towards successful builds. Anything else for technical documentation stuff? Yes and no, I'll leave it to the later item and we'll bundle it all within that section in terms of all the changes that have happened in the last two weeks. All right, a repository move timeline and steps. I was hoping Diana was going to be on to talk about coordinating the red hat folks with us, because I think that's the only thing that's stopping us now is making sure that the DNS team are lined up and we pick a time and date. I'm just checking in with her and send her a message to see if she's going to make it. All right, well, let's table that then because, yeah, I mean, really, that's the only thing that impacts us is just waiting for that. Okay, so then moving on to depersonizing homelab documentation. One of the things that I think Vadim is really busy. I know Shree is really busy as well. Let's just grab it ourselves and stuff it into a blog post. I, instead of like deferring to them to clean up or make any changes. I'm happy to have a go at that but I didn't know whether they'd volunteer I thought they had volunteered to do it I didn't want to step in. Well, no, they agreed to the, they agreed to the concept they weren't opposed to the concept. So I don't think they would mind. I'm happy to do that and put that down to me then. I don't lose a thread on that one though that we do still need to work out what future what future guide should be because I think there is a need. I don't think the documentation is enough that a total newbie can get started, which is what I see the guides off for. I mean, when I did my first install, I had to go find a YouTube video. Now, again, Michael, maybe that's something we can actually look at and see if we can do something in the documentation to try and, but there's a lot of a cablery in there in the first time through. It's almost like you don't know enough to be able to use a documentation. Once you've been at once it all just clicks into place. But the first time through it's like, I don't know enough to even know what the terms mean and what they should what I'm looking for here. So having an example, which is what I use the YouTube video for was that a harm moment. That's what that means. And then you're good to go. If we need the guides, then we need to work out what a guide should be. The other side of it is, should we try and do something to make the documentation easier for first time users where they don't know anything about anything. I can look at it. I don't think I've actually looked at the upstream docs. Yeah, because I mean, I mean, I give an example, even like the first time through it's like. Here's eight different environments you can use. It's like, which, which one do I use? It's like, I want to play with this stuff. It's just like, what can I get? What's free? What do I have to pay for? How much resource do I need? And it's all these questions. It's like a million of one questions where someone can tell you, if you've got a machine of this big, this is a step. Follow this step. And hey, press. So you've got something running. And then all the phrases like IPI UPI and this name and that name and that ID and that resource and all of a sudden these things just fall into place where if you're just reading it. From scratch, you're just sort of like, I haven't got a clue what that means, even letting know what the value should be. How do we want to approach this as a project then in terms of defining a a starting point? Well, first off, these sounds like two different things, right? Sounds like on the one hand we're talking about a sort of getting started a getting started. That's at the very beginning. And then a template for guides, right? For guides for particular topics. Is that, am I reading that right? I mean, what I'm saying is if the documentation had that lower entry point, I don't think guides become necessary then because the documentation covers it. But if the documentation is staying as it is, I think we need a lower entry point, which would be the guides. Well, so the guides was originally supposed to be if there's a particular angle that like, okay, UPI on vSphere, right? Like that's a particular thing that like maybe I think having that as a separate guide is always going to make sense. Do you know what I mean? Like I don't think you could write a generalized welcome to OpenShift or welcome to OKD that like gave people enough nuance to vSphere UPI while at the same time being a sort of general document. But that is in the documentation. vSphere UPI I believe is part of the documentation. So what was saying? Yeah. What was saying is a documentation a reference. And if it's a reference, then it's not a how to, then we need guides, but if the documentation should also be that how to, then we don't need guides. So I guess my question is, is the official documentation a reference for install? Or is it a how to do an install? Well, if we look at things are often in the wrong order for a guide in the official documentation. Yeah, I mean, if you look at, oh, sorry, go ahead. I thought you were done Bruce. Yeah, no, no, I was just going to say the like after you go through a lot of detail, then, you know, you find out something you should have done at the beginning. That's one thing. The other thing is that I've noticed recently that a lot of the reference documentation seems to be just additions that solve specific issues. And so now there's a whole bunch of accretions to the documentation so that doesn't read as a unified thing as much. I guess the things I read the most are the vSphere sections on installation. Probably true. That's a running complaint. Yeah. And one person described it as a manual that shows you all the instrumentation for a cockpit of an airplane. How it all works, but it doesn't teach you how to fly the plane. Yeah, right. Yeah, that's accurate. So, I guess, like, do we have a, you know, like maybe with the guides and then I'll stop. If we picked one. For reference environment. Because and then try to make a good guide there. It might be easier than fixing all of our guides. You know, because we've got, you know, like vSphere, we've got the, you know, various, you know, virtualizations on Linux. The F cost now claims that you can install it on. Virtual box, although I did that at the very beginning and it didn't quite work, but probably not works. So, like, there's, you know, so many possible installations, right? And I think if you were a total newbie that all those possibilities don't make your life easier. Because again, you don't know what to choose. And many cases, what you choose is not so critical. And, you know, so the, you know, some of the opinionated guides, like if we had one that we said, okay. All of this. This is your first one. Get that going. And then you can branch out. Anyway, I'll shut up now. I think that that's valid. I think that, you know, we. If we had a getting started got a getting started document that pointed to a getting started with OKD guide that was like, here's the most basic cluster that you could build on your home machine to familiarize yourself with this or whatever. So I could see the, the two of them sort of linked right there. So, if we were to get my home machines, not a Mac, it's not a Linux. Yeah, I guess. Yeah. Yeah, well, so is mine and actually the when I was playing with the tecton stuff. And running to roadblocks various places. What I finally did is I installed fedora. You know, like a virtual fedora. Again. And set up my tool chain fedora and that worked. Yeah, because it turned out that the, even after I got the right go version that the tecton people were using, which was back from the current one. Their scripts didn't work under either the Mac bash or Z shell, which is your, you know, what I'm currently using. So it's. And, you know, rather than debug the things to get it to work on a Mac, it was easier to do it from fedora. And I imagine I mean, Ubuntu would have worked just as well, I would guess. Yeah, so it does sound. It does sound though, like. What we're at the very least we do want a introduction to okay D for people new to open shift type document to at the very least. Is that what we're saying it sounds like it. I live on docs.okd.io or should that be on the community site because for me, that's the issue is do we want to try and get the docs to a point where there's a lower entry point. Or do we want to go and create a guide within the community section that use that then uses a documentation as reference for the actual. Is it easy now to, I know there's like a new document build process right. Is it still sort of like books, where we could have a book inserted in the, in the list of books basically as chapters. Yeah, so I mean if we came up with something that was nice and polished the way I think we could insert it into the into the to the docs. That okay D.io. The question then becomes, if we put something in the official documentation, we have to have a process of review. And, you know, like we have to have the same thing that basically red hat has for the upstream docs. We need to define a process for review. And we need to make sure that there's always someone who knows that it's going to be their responsibility. This time around to review that documentation and make sure that it's correct. So that would be parallel to this like we come up with the doc the first time then we also define the process for revisiting that doc. But about I think that that would have to be the same whether it's on our site or the doc site. Yeah, yeah. Yeah, that's because this this is something that would have to be revisited effective with every release. And the other thing that comes into this is, is when we get the SNL documentation. Is that going to lower the the sort of entry point for other installs because once we have the system the stroller process to find, we can use that to do a lot of the IP eyes for all of the different platforms. I don't know how it handled UPI or if it does at all gives you an easier starting point maybe creates the ISOs I don't know. But I'm aware that that might change the game for some of the other installs as well. Yeah, I'm looking I need to read through the thread that Glenn has in the chat because there's literally 100 messages over 100 messages that Glenn posted as he was working through doing SNL. So that kind of concerns me because if there's a lot of hacking that needs to be done to get something that's functional. So I need to check in with him and the DMC because he was part of that thread as well. And sort of see how they landed. The other thing that I think we need to be aware of though there is a possibility that we could host that. If we get this first cloud, then people wouldn't need to be able to run it locally because I think that's all the hacking is happening at the minute. Yeah, it's because for OCP it's hosted. But for OKD you have to effectively run it locally so you can then use it. And so, and so the next steps. Yes, I think we definitely need the guide. We need a lower bar a lower point of entry. But it's where should it be and what it should be and what platform should it be. I think are the next steps. Right. So I think the first step then is a discussion thread. Now, the, the S and O is that do we have do we know if that's going to go back to the standard way of doing it for 4.11. Because the standard documentation. For OCP and the way we're doing S and O for OKD are completely different, right? I mean that's. It shouldn't be now. It should all be through the assistive installer. You'll see. I believe. I believe OCP I believe is already there. But apart from you don't have to run it locally, which is where which is where we got stuck. I believe with 4.10. They removed the ability of just doing an IPI setting the worker nodes to zero, which is how he used to do it. I believe you have to go through the insistent installer now. Because of the way they're changing the initial boot bootstrap. I think it replaces. It does a an in place replace of that, instead of creating an extra machine and deleting the bootstrap is why I think you need the install. I might be wrong there, but I think that's why the change how the bootstrap works. And. So, yeah, let's create a discussion group. I just created a discussion thread actually right here. I'll add it to the meeting docs. And then I'll have a go at converting. The human trees. Post into a blog. What about the other things in there then I know because I know those two are, I mean, the rest of what we call guys on guides either. But they're less personal. Right. I can revisit mine and I think that's the first thing that I should do is revisit mine and decide where that should go. I mean, ultimately that might even be a blog post in itself. Do you want to move the multi blog post or do you want to change some of them to a standard guide format and. I think what else we've got here, let me look what else is left. I mean, we automated visa install prerequisites for vSphere UPI visa IPI deployment single note OKD installation. Yeah, I mean a lot of these are like. Some of it like the GCP one is like literally just a list of things. It's not. Yep. Yeah. And I mean, I think, I mean, all of these are almost a year old now. Yeah. I joined around the time of the original hackathon to create all these. That's when I joined this project. So all of these were created then so these must all be at least a year old. Oh yeah. Yeah. And single note installation is no longer applicable since 410. Yeah, I think I think blog I think these. I'm almost thinking, well, I don't know who who wrote those IPIs. Do you remember? Because one thing we don't have is is authors on these pages. Do we know who wrote the AWS IPI and Azure IPI and GCP IPI pages. Mike created all of this stuff. He put it all together. And so I actually don't know where it came from. I mean, some of them actually has have names in it. Those IPI ones at the bottom. I don't know. And I mean, to be honest, if we get the assistant installer running, they should be a button click. Yeah. They put IPI into standard cloud platforms. It should be a button click from the UI rather than a manual process. So that's why I say I think that if we get the SNO stuff running properly, then we get a lot of these IPIs for free. Yeah. And same with the vSphere IPI and all of these should come through that. Yeah. I believe the vSphere one gives you a bootable ISO file that then re-registers itself within your environment. Then just click a button and say go. Yeah. But I think we need a sort of a let's work out whether it makes sense to try and do something in the official documentation. Let's have that conversation. Can we actually create a lower barrier entry there if it doesn't make sense there. I think we need to come back to the guides. In the meantime, when we get the SNO stuff, I think we need to revisit every single one of these things that are left and work out. Does it make sense to keep them or should they just be sunset or move to a blog? Okay. Well, I think where we are. Yeah, go ahead. Sorry, I think the one thing that we're probably going to be left with is the UPI. I don't think the Assistant Solid does that for you. I think UPI is the one thing where we're going to have to go through and actually I think that's probably where a guide is needed if we can't do it in the docs. Right. Well, let's let's get started async on that discussion about a getting started base level guide or sorry base level document or page in the documentation even more specifically and talk about what do we really want. That document to cover so we can work in that asynchronously on that thread and I'll actually post that thread in the channel and see if anyone random wants to contribute some ideas because we're in the thick of it. Right. So I've been working with OpenShift in OKD for like five years now or whatever. At this point, we'd probably want to ask some people who don't know what would you like to know if you were to come to this fresh, you know. So, okay. Yeah, I mean, I remember my first one I couldn't do it with the docs. There was too much I didn't know to actually be able to understand what fields I needed to provide and what values I need to put in them. There was terminology I wasn't really familiar with. Yeah, I did vSphere UPI and it was took me a lot of trial and error took me a long time to get things running eventually did but but I also had the advantage of having an F5 for my load balancing up front and stuff and so that makes that a little bit easier. Right. Yeah. All right, so up next is Jamie was on mute there. Just something to keep in mind when we talk, talk about the docs.okd.io versus guides discussion. The powers that be here want to get rid of docs.openshift.com. When I'm told there's no reason in the world that we can't do the same build process to create docs.okd.io. But what are they moving to then? What's it? What's it going to be something we call the customer portal. Okay. So that's that's going to be something that that's going to be something that we can't like, like it's not good. We're not going to be downstream from that. Right. So we're going to have to basically maintain our own docs or we will still. So we can just from what I'm told, you know, close, you know, my managers say there's no reason why we can't do the same build process to create docs.okd.io. Okay. But, you know, who knows, maybe someone higher up will say no. Right, right. Okay. So the sources, the source is going to stay where it is. The build process is going to stay where it is, but the eventual landing place is going to be so my different. The formats will be similar in terms of the content. Correct. Okay. All right. Moving on now to community governance and processes. Brian. Okay, so this is a biggie. And with me doing the pictures with Christian in Dublin for okd. I actually have time to actually sit down have a good chat with him. And alongside that, we're trying to get the community involved in a lot of projects where we have a build process, we can do that. And we had a meeting today with some red hatters about creating operators in a community catalog. So I think we're about to change the community to a point where we can be as involved as we want to in this. We're taking some of the processes outside of the red hat firewall and putting them in a place where community members can be involved in if they want to be. So I think alongside that, we need to actually just work out how we as a community need to function, because if we're now having our own get repose. And that's how the operator catalog is going to be built. It's going to be built on. And okd project. Get organization, which means we can, we're now going to have to take pull requests. We're going to have to have some sort of governance and form of making decisions. And who accepts pull request. And I think we need a project board. So when we start getting into this, we, it's a fundamental shift from where we are today, which is basically an information. Community and sharing stuff and what we can do to a where we actually can take on some responsibility. So I think we do need to just think about how we're going to do that and what tools we want what process we want who needs to be involved in terms of people. And so we need to have some approvers and we need to actually have some formal process of if someone thinks that someone shouldn't be approved, how do we actually come to those decisions. So I think that is the first one. And then should that happen as part of the main group or should this meeting get. I mean, we've talked about this being more than documentation. This is more of the community. Call rather than should this become the, the community governance call for one to the better word that then feeds into the main document. So I think there's a lot of housekeeping and just stuff that we need to sort of get in front of. And just to bring you up to speed on some of the other meetings before we actually have the conversation. So when I was with Christian, we talked about the base images and the fact that they are actually defined, but they go through a number of proud transformations. So trying to work out what's actually in those base images is not trivial. And they are there's both a build and a base image available within the origin that we can use. But again, finding them, find what, finding what the tags are, what type we should be using. And we don't have that access. So Christian, and if you look, he's actually created the repo today. And we're going to actually have a an images repo in the OKD project hub. And they're going to mirror both the container file. And then we've also got a key.io project will have the images in there. So that's going to be the base images that we can use as a community to build all of stuff on. So that was one of the conversations. And in the main group, we talked about the hack and getting the community build operators creating an OKD catalog, which is parallel to the Red Hat catalog on OCP. Christian organized a call today, Jamie and I were invited to that. Where Red Hatters have got their project week this week where they can do their own thing. And there is a team, the community team are actually taken on board the operator. So they're creating a tecton pipeline to create to build operators. They're creating a generic pipeline. Hopefully they can then build a number of operators. I cheekily suggested they start with the pipeline operator. So they accepted that and taken that on board. So I'm hoping, again, there is a pipeline project in the OKD project, Github project. I'm hoping they're going to populate that with enough of a content that gives us our initial OKD catalog with at least the pipelines operator within it. And so that's happening. And that will then be the basis of the operator hack that we want to organize with the framework guys. And so that happened today as well. And Christian has agreed to do the base images and the build image this week as well as part of his work. So I think that brings you up to date with the conversations of what's been going on sort of in the background. But I think this all comes to head with now that we're getting stuff in there, we need to work out how we're going to actually run it as a project. Discuss. Discuss, right. That's a lot to bite off and chew. I think you're right. I think that this meeting is turning more into a governance meeting. Because the more that we deal with documentation. I've noticed that it is actually it essentially impacts the direction of the community as a whole, much more than sort of the technical conversations that happen at the main meeting, right? I see that we would need to create a team that is sort of a the technical team that would approve merge requests and other technical things. I see that we would actually need to define this group as a governance group and actually like make it official as opposed to us sort of calling it the documentation group and hacking on the governments part. And we did have a board before when I first joined the group. Diane was actually using a board, but it was never updated. So it was really hard to and it's probably still I think in the community repo. I think if you check under the boards there, you might see it still. If we're going to do a board, I think we have to update it continuously and make sure that that we, you know, configured in such a way that it that it's useful for the tasks that it should be used for. Bruce, what do you think? Yeah, I guess. Okay, so reasonable so far. One of my concerns when Brian talked about setting up a separate catalog was. Well, okay, if you have similar content to the official one, then you got a lot of operators. And with the official one, there's a way of keeping everything up to date. And it seemed like you would need that as well. And in some cases. Really, there are no tweaks that you'd have to do for okay D. It's just a matter of rebuilding whatever is the OCP version. Some cases it's just the open community version. You know, the Kubernetes version works fine. Some cases you've got a lot of deltas. And as I discovered when I was researching the serverless stuff. There's even new repositories that are not connected to anything else that keep popping up. So it sounds like it's a non trivial exercise. And we had originally been going along a path that would have would try to add to the red shift red hat people. The task of publishing an okay D version. Whenever they publish an OCP version. And the difficulty with that is it's not really their job. So you have to get them interested. Okay, so alternative is do it yourself. Fine. But then we have to have the assuming we can get the cooperation from red hat to get set up, which maybe we can. Then there is a question of manpower. Or person power, whatever we call that. We don't see huge numbers of new people. At our current meetings. So we would somehow have to get, you know, people excited to volunteer. So, you know, maybe we. Anyway, the, I guess that that's my concern. Is that we don't want to wind up with a catalog. Which, you know, a year later we're now on 4.14 and our catalog is stuck on 4.10. Right. And people try to use okay D and they're like, man, this catalog sucks. And then we have to say, well, hey, you need to get involved because we don't have anyone contributing to do this. So, but, but if nothing works for people, then they don't get excited enough that they're going to push on to where they want to get involved. So does it sound like, go ahead, Brian. I was just going to say, so I think part of the part of the challenges that we can only do this when we get things like the first cloud, or as we talked about in last week's meeting. There is this new red hat build system that they that we have an opportunity to become an early acts and early adopter of. So there has to be a build system that is running all the time that we can use. I agree that this is a non-starter if we have to do it on people's home machines and there isn't an official infrastructure. And I think part of the project that the red hat team are looking at this week and we want to continue in the hack is this has to be automated. It's not something that I mean, I believe Vadim has to do a certain amount of work to do an OCD release. So I think we need something where they were just scraping repose and comparing the latest release title. How do we do it. We want to make this as automated as possible. So we build it and then we can test it with a high degree of confidence that we can release it with minimal minimal human intervention. If we can't get to there, I think you're right. There is an issue if we can't get new contributors to the community that are willing to actually do some work and help us out because we are getting stress quite thing because there's only sort of half a dozen people that seem to be regularly contributing to the community. So I think they are very, very fair points. I think if it is the community one, we should push together put into the community hub. I only just found I shared the repo where the community hub is actually defined. It's a different GitHub organization. It's the Red Hat ecosystem organization. This is really the catalog that mirrors the Red Hat. And the idea is it's got to be built from the same source. The only change we're looking to do is just scrape out the from on the container files to replace the internal one with the with an external accessible image. The hope is that majority of the operators that will work. Although they did point out there are probably some older operators that may not be fully compliant with the current operator framework and process. And maybe we can help contribute and point them out and get them updated to use a standardized operator framework. So there is some conversations to be had there I would say. Well, this does actually highlight circling back to something that that is a recurring theme that that Bruce brought up. Maybe in parallel to this and it's again a lot to bite off and chew, but we need a recruitment process. We need to somehow get more people involved because it's literally the same five or six people. Right. And that's not enough to flow to a community taking on like builds and no matter how much automation you have there's going to be people that need to approve things. You know, and documentation and governments and governance and that's right. So maybe that's something that we should work on as well is coming up with some ideas of how do we recruit more people to get involved in the community. We I haven't looked at the survey yet, but I think we need to promote the survey to get a sense of what people want. And with the survey say, okay, you know, if reach out to us if you're interested in getting involved, right, here's a survey and reach out to us if you want to find out more about getting involved. I also think about if we have a board. It also helps people get on board because at the minute if someone wants to join a community. There's nothing for them to do it's or nothing obvious for them to do. There's no way of them saying, oh, I could have a go at that. So a lot of communities have the easy first first issue tag or things like that to sort of say, come and join us and this is the list of jobs that we were looking to get done. And some of them are tagged that these are the easier ones to help you get and so because at the minute when someone comes on our calls and actually met a couple at the two, two gatherings that I did. And they said, well, it can be quite daunting because there's nothing obvious for them to do to join to contribute. And it takes a little while to understand what we're all yacking on about because, as you said, we're in the thick of it. And we pick up conversations from previous meetings. And it's, it can be very daunting to try and come on board. And so I did tell them just ping me or just speak up and say, I haven't got a clue what you're talking about. Can you please give me some context. But I, so I think if we get a little bit more structure to how the community works, that's an easier way to try and onboard somebody because we can say, here's a group of things that we need help with. It's a concrete list and they can decide if anything meets their skill set. Does that make sense to have a, a GitHub project created with this. And the projects basically are a spreadsheet. In essence, a list of tasks, merge requests, items and whatnot. We, if we're going to use the OKD one for now, if we're assuming that that's going to get pulled over or do we create it in the, the other one, temporarily. I don't know. I think we have to. I was trying to think about that because they, if we're using discussions and we're using the other one for that for general chat. I don't want to clutter up. Maybe we need a planning repo. But we actually do just use the issues or for a GitHub project. And we can have a board and it. It's like curated tasks and it doesn't get cluttered by. People just raising issues of saying my install stuck and I can't work out how to make this operator update and. So I just. Yeah. Well, so, I mean, we can add categories though to the discussions, right? So we could add a category to discussions and do this. As. Yeah, I mean, so there's a couple of ways that we could do this. If we have a separate like. Community. Then basically we will end up sort of with what we have now. Only it'll be in our control there because there is the community repo now. And then there's sort of the technical one. So we'll just be mirroring that then. And we want to make sure that the 2. So, but if there's technical things that someone needs to do, then we need it needs to be cross repo. We just need to make sure everyone knows how to do cross link cross repo linking. For issues and merge requests and stuff like that. And then the the other. Tricky thing here is that internally red hat have Jira. And Christian has given us a link to the Jira board. But as yet. He doesn't think that community members can raise new tickets on that board. But we can see it. So there will be some things that will be getting done internally within red hat that will be on the Jira board. I think there's our community project. Which is going to be in the project. And my initial thought is that we have a planning repo. That hosts just that board and that project. And then we're going to have the main okay D repo, which is where we're going to have discussion items. And anybody that wants to raise an issue that's where they'd raise an issue. So the planning one. Is for only when we've identified a task and we're going to track the task. Okay. So that's my initial thought about so new person shows up. And says, hey, I want to get involved in okay D. We direct them to the planning repo. And say, look in this board for things that need to be done. Yes. Okay. With it with it with an easy first. Task flag on or something. And then we, we write up, I mean, obviously we've got to write up our governance rules and our processes. On okay D. So, and that's where we would point someone to one. And we'd have a within the contribution will create a contribution set contributing section. And we'll explain how the planning repo works and how they. How they can participate and. Basically done with community. Except for like moving over the. The charter. I thought we deleted it. Yeah, we did. We archived it anyway. So. We're basically done with that so we can create a new one that is. Just planning. I don't use it. Let me, let me ask this though. So in terms of the governance stuff. Is that a 3rd repo. No, I don't know. You want to put that in. You want to put that in. Okay. D. Okay. It gets too complex if we have too many places. Right. I think. Okay. Yeah. Okay. Is the landing place for all information about the project. Official document is in docs.okd.io. And then we have the planning repo for work. Identified tasks. And then the OCD repo is where the discussions live. And the community interaction and discussion happens there. And so basically the, the planning repo is for. People who are considered part of the working group is in essence. That's what it, that's the people who are participating. And when a discussion item. Results in. An action that needs to be done. So for example, we've sought the discussion item on. Guides and documentation. When we come to. An agreement that we need to go and create. This content. That would then move on to the planning board. In the backlog. With a needing to be done. And then that's where that action would be. And then we cross length of discussion. To say this is now. Being moved to an official activity. The discussions over here. So we shut down the discussion. And move it to planning. But while we're trying to work out what needs to be done. It stays in the discussion forum. Okay. So let's. Formulate this. Into a. Coherent thing to bring to the main group. Next Tuesday. And. Maybe Brian, maybe create a bulleted list of things we want to touch on. Or add it to the meeting notes for next week's meeting. Just bolted items of things that we want to bring up that came out of this. In the covered in the, in the updates from the. Documentation subgroup. And then let's bring that concise. List of things to the main group and see what they say. And I think just go from there. We'll see what other folks say. To be clear. The three or four of us. Five of us. Are probably going to be doing a lot of heavy lifting for the community. We're going to be doing a lot of heavy lifting for the community. For a while. So folks have to kind of be invested. If we create a separate repo. And whatever, then we. Essentially have to be committed until we get more people involved. To maintaining that. To make it appetizing for people to get involved. To. You know. To help maintain it. All right. Any last thoughts? We've got five more minutes. If there's any last. Minute needs. Last minute things to discuss. Does anyone here know? Oh, go ahead. I'm sorry. Does anyone. Does anyone here know. How a feature gets. Excluded. Okay. D. And shouldn't be. Is that more of a Diane question. Yeah. That. A feature gets excluded. I think. I think. It's literally just. Is there something proprietary? Not proprietary, but something. With red hats stuff in it. Like an operator or something. Do you know, like, I don't think they actually. Oh, go ahead. Sorry. I actually don't think it's, it's, it's, it is that it's all because. As far as I'm aware, everything in open shift. Is in open. Is in the open GitHub. The only bits that need to be excluded are where. Okay D doesn't have that feature. So. Most of the operators. So all the core is the same. So what's in the core of OCP is the same as the core in. Okay D. Built up the same source. Obviously there's a different underlying rail versus. For dollars. So. The only bits that need to be excluded are where. Okay D doesn't have that feature. So it's a different underlying rail versus for Dora. But where we are missing functionality is all the add on operators. Right. Which is the conversation about creating an okay D catalog. So features like. And the serverless. Like. Get off. Like. Like storage. And. Features that require the advanced cluster manager. Features that required the. Assisted installer. These are all. I think it's called OCP plus. Which is all of the additional bits that surround. Same with the security manager. These are all pieces. That are delivered in the red hat operator catalog. Where the equivalent is not being built for okay D. We only have the community catalog. So they are the features. That need to be excluded because the operators aren't available. To okay D. And what we're trying to do is make. A lot of them available. And to okay D. So. I'm hoping we don't have a. We don't have a list yet of. We have a list of operators that that we would like. But we need to drop. I get a little crisis going on here. Okay. Okay. We don't actually have a. We don't actually have a. Like a translation of what those operators actually are in terms of features. Which might be helpful because that'll help Michael with documentation. Because he's got to know, oh, I need to pull out the GitOps. Section and stuff, you know. Yeah, there's actually an exclusion list that would be useful to have. Right. Just sort of raise up. The higher visibility. Like some of them are sort of obvious and we keep mentioning them. But. The, I never thought about the security thing, for instance. Although I was wondering about. The. Multitenancy recently. And looked and found that there was some multi-tenancy stuff on OCP that didn't seem to be obvious and okay D. And so a list list are often helpful. But yeah, no, the, like I am optimistic about the new plan. Even though I do raise concerns as is my want. Don't take that for pessimism. Yeah, sorry, Bruce, just another point that you raise that I didn't answer is. A lot of the red hat engineering teams are very resource constrained. Which is why you said, I mean, if you look at that link I sent. Which is the ecosystem. There is an okay D repo for an okay D catalog repo there for where they should have been populated. And there's not a single one being populated. And speaking to Christian, he doesn't think that that's going to happen anytime soon. So we've already been waiting for red hat to help us out and populate this catalog for four months now. And I think the consensus is the pressure on the engineering teams is just too great for them to expect them to do that for us. Which is why we're now coming up with the ideas of let's enable the community to build these catalogs or this catalog. All right, well, that's a lot to chew on. And so let's let's call it a day. Because I've been in two hour long meetings for okay D today and. Okay, so we will bring a list of things to the main meeting. We'll see what folks think and then let's get started. Assuming everyone is on board with on the one hand. Trying to drum up interest and participation and what chicken egg situation goes hand in hand with that is getting this. Assuming everyone agrees community board set up so that people know specifically. How they can contribute and what we're looking for. Yeah. All right, thank you so much folks. This has been a great meeting and I'll see you online.