 All right, thanks everyone for joining in for this edition of the Fedora docs workshop series. So this workshop was titled advanced techniques for editing and contributing to Fedora docs. So most of that for the context of this conversation today is going to mean the command line, which may or may not be advanced depending on what your perspective is on these things. But my point of kind of going through this agenda today is to show you one way of of editing and contributing to various Fedora docs repositories and content. Regardless of whether it's Pagora or GitLab or wherever it's hosted, even GitHub, you can find a few Fedora docs reports on GitHub. But my point of this is to really kind of showcase different tools you can use for your own and creating your own workflow that lets you use your own tools, use your own preferred text editor and environment. And then to show you kind of best practices about using these tools and workflows based on mostly on my own experience being involved in the Fedora docs community for a number of years. But then also to share some like depending on how much time we end up with towards the end, a little bit of guidance on also like how all the all the pieces get strung together. I won't be covering every detail for that, but just to give you a sense of how all this different repositories of docs get strung together. So in short, here's what we're going to be covering today. We'll do a quick introduction to working with Fedora docs from the command line and using containers to build your changes and preview them to from the command line approach how you raise a change proposal on pagore and GitLab. And then third and finally, a very quick introduction about how to publish a new Fedora doc site and how the entire Fedora docs website is built. Again, not going to go into every detail there, but just to give you a sense. Before we get started with this workshop, if you're following along at home, I'm going to assume that you're working, we're going to be working from the command line today. So if you're running Linux or you're running Fedora, that's going to be pretty easy. You'll either have the GNOME terminal app or a terminal interface tool of your own choice of which there's various. Assume that you'll be using like the Bash shell or Z shell or one of these kinds of things in the terminal will also be using Git. Podman or Docker depending on your preference there. And I assume you have at least an account on one, if not both of pagore.io and GitLab. So with that, I'm going to go ahead and switch over to the first part of this workshop. So we're going to be looking we're going to be working from the command line interface or CLI, which is what I want to hear me say CLI that's what I mean. So we're going to be looking at navigating the terminal, installing some prerequisite software that you need to be successful and working with the docs, setting up your own writer environment. And I'll talk a little bit about this thing that we call the feature branch workflow. So I'm going to go ahead and share my screen, which should work here. Let's try this. Or maybe I need to do a window. Okay. Someone confirmed that my screen is visible here. I hear here. Yes, and a thumbs up. So I just have here is my my terminal environment. So what I, I'll kind of walk through about where I am right now. So we're going to be looking at both two repositories for today's demo. Let me go ahead and link these two repositories in the chat. We'll be working with one repository on pagore, which is the quick docs repository. Where is the chat. Does this jitsi room have chat disabled. I guess you're supposed to use the matrix chat. I guess that would make more sense. Okay, let me open and go back to the matrix room. And I will put here a link to quick docs. And then the other repository that I'll be working from one on get lab using. I'm going to use the D the diversity, equity and inclusion teams doc repository. Oh, Renee, you're seeing a black screen, huh. And I'm not the only ones are the issues with on my side, right. I am the only one with the black screen, right. Yeah, try refreshing and see if it comes comes through for you after refreshing. If not, then I can try something else. Sure, the better now. Yes, now we can see your terminal. Okay, perfect. When in doubt refresh. Okay, right. So I put the links. Oh, now I was going to put this other one into the matrix room chat. Oh, I did. So I put one get lab. Oh, then Falcon, are you able to. Are you able to see it? Okay, yes. Great. So, I'm going to, I'm before I'm going to get into the details here, I want to take a step back. I'm going to open actually a fresh window here as I want to talk a little bit about some of the dependencies you'll need so let's say that you're following along from home, and I'm using Fedora Linux 39. And so the dimensions will be pretty much the same, whether you're on 37, 38, 39, probably even 30. But there's going to be a few things you need. I mentioned that we're going to be using containers and get today. So if you're working from the command line, you can do a pseudo DNF install which is the DNF being the package manager for Fedora, and you're going to need these three packages package to need the pod man package and you'll need this I notify tools package. So type in password here now I already have these things installed that's probably going to say yep, they're already there. But I will put this command into whoops into the matrix room as well. So if you're following along from home, you can just run this and this will basically provide you from Fedora or probably from some other RPM based distros. I think the package names will be similar. You could also be doing this from the windows subsystem for Linux, but I think you're probably going to be running Ubuntu or or Debian on WSL. You'll have to consult the docs for your distro if you're running something other than Fedora to do this. So this flows with your based on windows that you can use these tools, but given I'm not on a windows environment, I'm not going to spend a lot of time on how to set that up and run it. Again, if you are in windows you can use the windows subsystem for Linux, which will give you that Linux environment and a shell that you can work with. But if you're on Fedora, that command that I put into the docs channel will install you get for the version control podman for the containers and this other tool which is needed for the build scripts, which I'll talk I'll come back to that in a little bit. Once you do that you will then need to you'll have all the dependencies and things you need. Next you'll have to clone down the repositories and set up your workspace a little bit. I'm going to change windows here. I'm going to go to this quick docs window zoom in a bit so you can see hide some of that it's not important. I have this hierarchy I have a get folder, and I have a bunch of things for all the fedora docs results. So for me I've got a bunch of different repositories are all different docs repositories that I work with more some of them more regularly than others. But I mentioned I'm going to be looking at two of these today, which one being quick docs, and the other being the DEI team docs to just to give you a taste of a Pagora workflow and a get lab workflow. So I'm going to look at quick docs, which I've already cloned down, but if you're following along from home, you can clone that repository. So there's kind of two ways to do it. If you're going to be working from Pagora, you'll need to have SSH keys set up. If you're going to push your changes from your local machine back up to Pagora, so you can make a pull request to like a repository. So I'm putting two commands in the in the chat. The first one is the SSH link, which if you can do that one that's the preferred one because that's what will let you actually push your changes back without having to do actually I don't think Pagora works at all with password. Over HTTPS, but if you're not set up to do all these things that's okay, you can use the second command that I just put in the chat to get clone HTTPS Pagora quick docs.get. And that should work regardless of whether you know anything SSH keys or not. So you should be able to pull down what I'm about to show you and even follow along. If you have those dependencies and you clone this down, just you'll, you'll, you'll get stuck after you request, then you'll have to figure out the SSH key part. But that's okay for now, because we're really trying to talk about the workflow and how you can use your own preferred tools and environment for doing these things. You might have to do a little bit of setup for git for the first time, but I'm not going to do a ton of overview of how to set up git. There's lots of really great work documentation and guides online that can kind of guide you through how to set up git for the first time. But then, yeah, so like, so let's go ahead and say like, you know, you do the git clone, you know, the, in my case, I already probably have it with the SSH. So actually I have a fork here, which I'll talk about that in a minute, but you might have something like this. Like I've cloned down, that's my git remote. My git remote is kind of like the online hosted repository that's not on my machine. It's remote for me. So that's why it's called a remote. Now you'll see I have set up to here. I also have created my own fork of the quick docs repository, which just again some like context of like best practices and workflow, especially say you don't have commit access or you're not a member of the Fedora docs team today. So if you're not a member of the docs team, you're not going to be able to push changes to that pag or IO quick docs repo. You're going to have to create a fork. And now maybe I can shift my screen share here. I'm going to leave the terminal and go to the browser for a minute. Let me just change my screen share so you can follow along. Okay, I hope my screen is still visible here with quick docs window. I see a thumbs up. Thanks. So if you're looking at this for the first time, you'll see a few options like all those links that I just put into the into the matrix room chat. There they are. You can find them here. For me, it'll save you fork because I've already made a fork, but a fork is like just making a copy of another repository. But when you make the fork, it'll push it to your own account. So like here's my fork. I have all the access here where I can do anything I want that's all on my name space. So it sets a separate copy. But the benefit of doing that is then I can make all my changes and I can push them back to my fork. And from my fork, then I can later make a pull request back to the original. So I would suggest, you know, if you are going to follow along with this from home, you always want to best practice in general is to make a fork of the repository that's kind of your own working copy of the docs repository. And then you can feed that into a pull request at a later point. So just a quick context about best practices there. So like that's why when I had my terminal window there, which I'll share that screen back again. Everything's still visible there for my terminal window. Perfect. So that's why you'll see here I have these two remotes, which I only get super important for the context of right now about, you know, how this works but in this case, when you do that get clone step that I put into the matrix chat. Actually, you'd want to do a get clone of your fork. That's the one that you'd be able to push your changes to. So, okay, so now we're here we say we've cloned the repository. You know, so here's all of the things that you can find in this repository, the same things that you'll find if you're scrolling through the files on pagger.io. So I already mentioned, well, I know here's one more thing about kind of the setup and kind of getting yourself oriented. I'm going to be talking a lot of well I'm going to be you'll be watching me use this workflow called feature branching, which is really common in general when you're working with a get. I mean a lot of the used in software engineering but it also works really well for doing content changes to things like fedora docs. So you'll see a branch. So you'll see here actually I have this main that's here on my terminal window. So that's telling me, you know, here I am here's the quick docs repository that I've cloned I'm in the main branch which is the default branch of the repository. Which that's when you know if you go look at pagger.io for the quick docs repo, all the things you're seeing there is the main branch. However, when you're working on your own changes, the best practice is never to commit directly to me. Generally, you always want to create a branch, which is kind of like it sounds it's like kind of like kind of like a fork, except instead of a different repository. It's a fork in the same repository. So if you look at this get branch command, you'll see that I've already actually created some new branches here which I'll be kind of walking through during this workshop on how this works. But in general, you'll do there's a, I'll show the help message here for get branch. It's a little long I wanted the short I wanted the abbreviated version. So that means here not all of it is going to be very relevant. But the flag that you'll want to look for here is check out. Wait, I'm sorry, I'm using the wrong command here actually, you'll want to make a new branch, but do that you actually use the get check out commands. So say you've cloned the repo down, you're in the main branch, you'll use. Okay, I wanted the abbreviated version again. Let me get the short message. Yes, this is what I was looking for. So when you want to create a new branch, you'll use this uppercase B, or even in lowercase b flag to create a new branch. So say I'm on main, I'm going to get branch dash B. I'm going to call give it a name my new branch. Oh, I used I used the wrong command again, not get branch get check out check out the checkout dash B my new branch and you'll see ha, here we go. I switched to a new branch and you'll see my branch has changed here in my repo. And it's the exact same copy is what's in main. So I'm going to open the get log here and you'll see, these are all of the commits, all the changes that have been introduced to the repository. They're all here and these are the same things you can see that are already in the main branch. They're also here as well, but it's just a straight copy. See here's all these changes that people have been making over the last couple months. Going back to the January. So that's why whenever you're going to make new changes when you make that new branch you do get check out dash B, my branch name or my change name. And now I'm okay to start working. So now that I can start making my edits and my changes. You can get to work. But you know, I want to also talk a little bit about the structure of how in a fedora doc site is built and made. Some of this is confusing. Okay, here's this modules thing is a public folder and all these scripts that are here. How does this all fit together. When you're doing things locally on your own hardware as compared to say using a web ID on get lab or pagore. You'll interact with some of these things a little bit more. So I want to I'm going to change my screen share again, and I'm going to take you to some documentation from the and for a project. And also share a key distinction here as we move forward is that you'll hear ASCII doc and you'll hear and brought up a lot when you're working on fedora doc and they're two similar but different things. So ASCII doc is the markup language that we like our documentation. Maybe you've seen or heard of markdown already, you know, ASCII doc kind of being just another flavor of that and I'll pull up a reference here. Let me go. The screen visible again. Got a thumbs up. So ASCII doc, again, is the syntax, you know, that, you know, all the formatting that's used in the documentation files, which we'll look at in a minute. I will put that link. So this is for the docs, but then we use this thing called Antora. And Antora is kind of like the build tool that we use to take all the ASCII doc files and serve them up real pretty into a, you know, a finally built website. So Antora is the tool that takes all of our content and builds it into the docs. And when you're working in a fedora docs repo, you're going to see a file system layout that looks similar to this. And I'll put this link in the chat as well, because I always find this really helpful to look at. You'll see also on the sidebar to the setup content sources category. There's a few different pages, which might be helpful reading. I'm just going to talk about this one really quickly. But when you're working with content, when we're looking at that file tree, usually what you're going to be looking at is this modules folder. That's where all the content and the actual ASCII doc text lives. Some repositories will have, you know, different modules inside. You'll often see this root module, and that is usually like the default one. If a project is not so complicated, it will probably just have this root module. However, sometimes other repositories like the DEI repo, which I'll show in a little bit, it has multiple modules. And there's no difference between them, but they're just organized in different ways. So let's say that I'm looking at the quick docs repo, which we'll look at where she will look at in a minute. Everything is in the root folder. All the pages, all the folders, everything is there. And in this case, it'll all be in the pages folder. That's where the content lives. So just sharing this, you know, kind of give you an overview of like what this structure is looking like when we're going to be working on it from the command line. Let me go and switch back over to the terminal window here. Move some screens around. Okay. And terminal window is visible again. No one says no. I got thumbs up. Thank you. So yeah, now this might make a little more sense. Some of this is you did not see in that file system tree, like there's a build folder, a cash folder, a public folder. Those get generated by our build scripts. You're never really going to be working inside those directories much they're not even committed to the get repository. So like I said, we want to change directories to the modules folder, because that's where everything lives in here. And like I said, you know, some repos, they'll have more folders here, but quick docs just has one, the root folder. And if I do that, you'll see again those same folders. There's that nav file, which has all that sidebar navigation for all those different pages that are on the quick doc site. You'll see all of these that are there in the sidebar. But then the pages folder, that's the interesting one, because that's where all of the quick docs pages are. So now let's actually take a look at making some changes here. And actually I think I need to share the whole screen instead of just the window. So I'm going to talk about my screen share one more time. Sorry for the disruption there. But I think now you should see my entire screen instead of just the window. Then I can also do some screen sharing with the preview. But okay, so I'm going to I did pre prepare some branches before this workshop. So I'm going to kind of skip around some steps here. And in terms of like making content changes. So let's say, so for me, what I want to do is I want to change the landing page of the quick docs website. So I'm going to open up. So just to give you an idea of what I'm going to change. I want to change. Oops, that's not the window I wanted this way. So I want the DNS upgrade page, this page. So say I want to make some changes to the landing page of quick docs, just because that's kind of the easy change that I have here in front of me. So that's great and everything. How do we do that. So if I go back to the terminal, like with many HTML examples, we'll go into pages, there is a index file. And this is where kind of coming back to the thing I mentioned at the beginning of the workshop, you can use any tool you want from this point. You know, like I'm going to be using you'll see me use a mix of the them editor and the command line as well as sublime text. Those are the tools that I choose to use because that's what's easiest for me. But you may have something else. You may like VS code, you may like Emax, you may like, I don't know, I could probably if I really tried to come up with like 20 or 30 different text editing programs, you could even use g edit on Gnome. Like the point here is that you can really use any tool you want. So I could open up them, which is the command line editor that I use. And we have already made some changes to this file. Here's this Hello world ASCII doc is fun. And that's that same landing page that's here, but you'll see my changes have not yet appeared there. So, I'll show you another kind of easy command. I want to take a difference of, you know, what's the changes that have been committed here. Oops, we just want to hit. So see, look, here's my changes that I've made. Hello world ASCII doc is fun. This is not yet committed. Maybe a line, I'm going to line change there, which is really mad. So when I'm working from the Fedora doc site, there are some build scripts, which I'm going to go back to the main folder, the root level folder where we have all these things. And depending on the repository you're working with, you'll see both this build and preview script, and then you'll see this docs builder script. The docs builder script most repositories, I think have this script these days. And this is what you would run. So I'm going I'm doing a period slash docs builder, I'm calling this script. And what this script is going to do is it's going to pull down some containers which are like kind of like a virtual environment with Fedora. It's going to pull the changes like all the tools needed to build and preview the stock site, and it's going to give me a preview that I can actually look at. So if you follow the steps earlier you installed git you installed podman and you installed that I notify tools packages on Fedora. I run that you'll see okay it's going to build a bunch of things and there's a few errors and warnings in here. Some of these are expected because they're in different repositories. You'll see the preview is available. And let's go and take a look. So we'll see now and you'll see this is all on local host this is all from my own browser running on my computer, not online on the public internet anywhere. But then here's my changes, and you can see the whole site that's here for quick. You know, the installation pages, the contribution pages, it's all here that I can click through. And this is all just being running is all running from the container image like you can even see like here's my. The traffic coming in on the logs now that the container is running. See I went to the quick docs page the contribute to quick docs page. It loaded some images. I went to the creating and using a live installation image page. So, and then this is also how you can see my changes. So let's say you were making some content changes and you made all your edits looks great. All ready to go. You run that build script and you can preview your changes. So that's one way of doing it. But there's a shortcut that I use sometimes if I'm not. I'm just opening maybe one file or I'm just wanting to look at something. There is a browser extension, which I believe I have ready. Open that. Oh, I think I just turned it off. I want it on. I just want to find the. Here we go. This is what I wanted. How do I open this into the Mozilla extension store. Anyway, I know I'm not going to get into it but there's this one called ASCII doctor.js live preview. And all it does is it will render ASCII doc files as HTML in your browser. Once you're not going to have all this fancy formatting of the Fedora docs theme, but just to give you kind of a proof of concept here, open a new terminal tab. And let's say I want to preview that index page modules root pages index. There's my file. I'm going to invoke Firefox here and Firefox is going to open that page for me. And there we go. Here's that ASCII doc all rendered up in beautiful HTML. Now again, obviously not the same here, but you can quickly test or verify your content changes. And like you'll see here literally I just opened the file in the browser that's already on my system. It's a little shortcut. You know, if you just want a quick way to preview some changes without having to do all the container steps, you can use this ASCII doctor.js live preview extension. And I'm using it on Firefox, but I also know you can find it in the Chrome extension web store as well. It's a little shortcut there, but I'd say in general if you're really serious about making some contributions or if you're working on like say a big change like I might do this if I have a small change. I just want to preview something super fast. But if you are making some big changes or you're just kind of routinely working on docs, the build script way with the container is the more proper way of doing it. So we'll go back to the quick docs repo here. So I mentioned like hey what if you want to make a pull request. So let's go and switch over to that. So I have my branch that's here. And if I look at the git log, I'm going to use a special command that I have. So here's my commit. And my commit is on this example. It's on that feature branch that I made example edit homepage. And you'll see here. Here are the last changes that were on the main branch. That's in that if you go look at pagard IO quick docs right now this is what you'll see is the last commit. So here's my change that I made to the homepage. So, from here, I would do git push. I remember the long form for you. I like explain the flags a little bit better set upstream. So what we're going to do here is we're going to take the remote. That's on my local machine. And we're going to put it on to the online under my fork repository that I had in the very beginning, which in this case my fork I've cloned origin. I'm telling I'm telling get I want you to push this this feature branch, this example, the edit homepage, I want you to push this branch to the origin to my fork, and I want you to connect that local branch to the remote. Let's go ahead and do that. We'll give it a minute here. And there it goes this is where you need the SSH key to do the pushing if you're on pagore. Oh, that's interesting. I haven't seen this error before. But that looks like something with red is that does not look like an error with my push that's something, something different here. But you'll see this is the magic link that I'm looking for is like hey, create a pull request, for example, edit homepage, and I can literally just click that link, and it will take me straight to pagore. And it will pre populate my pull request with the changes so there's the body of my commit message there's the name of the commit message. So this is a test from the Fedora docs workshop. Today's date. And I hit create pull request. You can see there's my changes that I made as well. And here it is all on pagore ready to ready to get reviewed and possibly merged in this case not actually, but you get the idea. And so this is going to the quick docs repository. I don't have all the time I had something interesting to show about rebasing, but I don't think I'll have time to run through that for today's workshop. I want to make sure we have time to also look at the get lab side of things, which is pretty similar. Almost exactly similar actually, but just kind of give you a look and feel of how that, how that looks. In this case, I'm going to say I'm going to go back to my I'm going to check out my main branch because I'm done on my feature branch now. So whenever I'm done I like to always reset back to the main branch to keep myself there. So yeah, we're done with the. Now let's look at a get lab example here. But again, is almost the exact same thing. All the things I did in the terminal that remains true where I'm tiger on get here. Let me explain some of this ago. So I only have one remote this time this time I don't have a form I'm working from. So here is this get lab repo, but this I think I put it in the matrix that already. So here's the Fedora DEI team document. It's all on get lab. Hey, look, here's that same structure, all the build script. I guess this is actually an older one is that build and preview script. It doesn't have the doc builder script. But it all works the same. This time I have to do build and preview. So a little bit of an extra step there. The same thing if I click here and I open it. Hey, look, here's the preview of the doc. Same approach, same general approach. So let's take a look at the future brain. In this case, I've actually got one already kind of set up from a change that you were changing or changing a page in our doc. In this case, I think I've already pushed this brain. I'm just trying to give you kind of a look and feel here. I'm not going to cover every single detail, but you know, let's say, hey, I've made my changes. Here's the main, where main branch is. And then I have a couple of things that are in my future brain in that brand for you. I'm just going to check and see if I go back to this branch. So rebasing is the step. So let's say I made these changes, like I'll open this pull request and show it because I have already opened it. So you'll see, like, here's that pull request. I've already opened. You'll see this was actually a while ago. This was three months ago. It's still open. Oops, I got to follow up on this one. But sometimes what happens, you know, you open a pull request and some changes happen to the main branch since you make that pull request. This is why feature branching is so helpful and useful is like, oh, like there were some new changes that were made to main branch that happened since I opened my pull request and easy. Probably the best practice is to use this sub command of get called rebase and what a rebase does at a very high, not scientific example or explanation here is you're kind of replaying the history. Here's my custom. Here's main branch. And then I layer on some changes on top of that. But then there's some other changes that are on the main branch. So rebasing kind of like it puts my changes up high. And then the rebasing will like stick all the other changes from main branch back in. And then it will put my changes on top of all of that. And that makes sense. I don't know if I have those changes here, but I'm going to do a get. Okay. Not exciting at all. It's already up to date. I thought maybe I couldn't write changes here or not set up. I had this in the other quick doc repo, but I want to make sure I have time to leave room for Q&A and also talk a little bit around how the organization is set up. This is again, I'd be happy to talk about this or if you have questions about this workflow and be happy to talk about that in the docs channel or in the matrix room. You can always ask me about that. But this is kind of like the reason why feature branching when you're working from the command line especially is so important. It's really easy for me to go and say, hey, I want to go check out the main branch. I want to pull any recent changes that are down. Let's get them already up to date. And then you can check back out to that feature branch. And then you can rebase those changes you pulled down on them now. In this case, I'm already up to date. And then some people get merge conflicts, which can be a little exciting, but that's going to be more general working with Git. It's kind of an advanced topic of working with Git, which there's plenty of videos and tutorials and things you can find online for solving a merge conflict or how to do a Git rebase. But that's generally the kind of workflow I'm trying to show here when you're doing changes to a docs repo. Having the feature branch just makes this approach a little bit easier. So let's see, look back on my outline here. We've got about 20, 15 to 20 minutes left. We've talked about kind of navigating the terminal environment, setting up your writer environment, if you get feature branching, talk a little bit about editing the content and working with ASCII docs. And then also how to preview your changes, both with the build script tools as well as the kind of hacky browser ASCII doctor that they asked like. We've also talked about pushing a feature branch to tag war, opening a pull request, you know, and then anybody can leave reviews on that like for quick docs, there's going to be a review process. You have to find a committer who can then review your changes and we see that before it gets merged into the quick doc repo. Same general approach to Git lab. Sometimes there's variation from team to team and Fedora on how to do these things, but the pooling remains the same. So let's, in the last topic, I think we'll have time to talk a little bit about how all of the docs we've posed with build and compose and also how you can add a new repository into the build system for Fedora doc. I'm going to go ahead and merge some windows and bring something back. You can window rearrange it in just a minute. So, you know, we have all of these different Fedora docs. We have all of these different. Here we go. We have all these different doc pages and project server and IOT and council and mind share and engineering. But how do these all get built? How do these all come together? This is where I talked a little bit about Antora earlier, you know, Antora is our build or build system that we use for our doc. So Antora takes all these different repositories. It takes the quick doc repository. It takes the DEI team doc repository and it goes and builds them all. And well, how we have it set up in Fedora is that about, I think it's about every hour and Torah will rebuild all the documentation and the entire project. And then that was published on doc.fdorproject.org. So let's say, you know, first answer the question like how does that all get done? Where does that happen? And it happens in this docs FTO review that I will link into the matrix that I am. Oh, I feel so terrible at keeping up with the chat here with having a different work space. But I hope this has been, I'll leave time for question. I really want to leave time for some Q&A. But there's this magic repo, which if you look at the first time here, like, what is here? There's nothing here. Read me. There's no style. That's not helpful. Well, you actually have to look at the branch of this repo to get to the helpful thing. So in this repository, just the way it's set up, which maybe isn't the most intuitive, but I'm not here to talk about that. There's two branches, this prod and staging brand. And so staging is kind of like our test environment. So say you have some changes that you want to build or test, but you don't want them to be built in the official docs at FedoraProject.org. So here is a staging branch. It's kind of like a testing sandbox. And then there is the prod branch. And prod, now you'll see if I open prod, here's a bunch of different files and build scripts, doctor files, configuration files, a bunch of things. So you have to remember when you're looking at that doc, FPO repo, you have to change the branch to really get to the meaningful stuff. Over here, we're looking at the prod branch now. These are all the files that are in the repository. Now, for our purposes here, we're really just interested in this site.yml file. Whenever I'm going to this repo, that's pretty much the only thing that I'm here to look at is this site.yml file. If we open that up, you'll see there's a little bit of definition of like, hey, Fedora docs, it's built here, telling it where to start. But then you'll see, here's a bunch of repositories. You will find every single repository that is ever built on docs at FedoraProject.org. They are all here. And really, it's just this section that if you're someone like me or you're someone who's working with the content, you're just looking at this content section. I'm not really looking at anything else, although there are some a little more advanced things going on here, but I'm not here to really cover that. Let's say you wanted to add a new repository, you would just start a new line. You know, you make a fork of your repository, make your changes and then make a merge request back that you would need to add a URL of the Git repository, the HTTPS repository here. Here's the Fedora Astafi doc. And then you have to tell it which Git branch it should look at for building your doc. From this case, the main branch. And that's it. That's all it's here. But you'll see also, you know, just to point out, like, hey, look, here's the QuickDoc repo as well. QuickDoc is here. We looked at the DEI team doc. There's the DEI team doc. It's all here. So again, there's a lot of things that are going on in this repository just to give you an idea of like how these all get built. So Antora is going to take every hour the way we have it set up. And Fedora infrastructure is to go and, you know, do a Git pull on all of these repos every hour and then run the Antora build script that generates everything and pops it out on doc.fdoroproject.org. So I think pretty much the outline that I have here, you know, just a recap. We talked about working from the command line, navigating around the terminal, what dependencies you need, how to set up to get branching workflow. We talked a little bit about content and working with ASCII docs and how Antora fits into this. We talked a little bit about how to preview your changes, either with container builds or with that ASCII doc browser extension. We showed you how to make a pull request from Tagore. We kind of showed you how to do it in GitLab. It's pretty much the same. You'll get that magic link that you'll spit out after you push your branch to the remote. Like, hey, did you want to make a pull request? Open the link and it'll do that all for you. And we talked a little bit around how all the Fedora doc sites get built. And if you're building a new repository, where you need to go to add that repository to the Fedora doc building. So I know I've put a lot of links. I'll make sure I get some more of these links that I have been talking about, including the matrix chat. But I'm going to go ahead and turn off my screen show. And we've got about 10 minutes left here. I'm happy to take any questions from the audience or if you want me to cover something else or if anything wasn't clear, feel free to use the hand button on Jitsi. And we'll use that to build the queue. Yeah, Renee. Yeah, thank you for the workshop. I have some questions regarding the translation and where we find the German documentation, for example. Where translations are stored and where to make them. Yeah, exactly in how to contribute to or by translating existing documentation. You've asked me my week question. I will say, I'll give you the I'll give you the short answer and the long answer. So the short answer say like, let's say you just want to do translations. Well, we use a little tool in fedora called web late that helps us manage all those translations. And if you see my screen here, this is that translate dot fedora project.org, which I will put that link into the matrix room. And you can find a bunch of projects here, but you'll also see there's these fedora docs L 10 and repos. And this is where you can translate different fedora docs repositories like quick docs actually here's quick docs. So say you wanted to translate something in quick docs into German. I have to remember how to do this. Actually, I think here we don't have any German started. We've got a little bit of check, a good bit in Spanish and Brazilian Portuguese, but I don't see any German, actually, which is interesting. But I remember right so let's say I want to translate. It's been a long time since I've gone through this so I'm going to try to remember a bit. Let's say I wanted to do Spanish, those files already done in Spanish, how about I'll pretend I'm French for a minute. I can translate. Yes. So when you're here, I'm not going to do I'm not going to make these changes because I don't want I don't want the French reviewers to get my garbage translations or invalid translations but you'll see that you have these it'll give you a bunch of strings so here's the English string. And then you can type the word in French. You can also flag if you need if it needs more editing or you're not sure you need to have more review, but you'll just keep going you can make the suggestion. I'll have to sign in I guess I'm not signed in, but you guys kind of keep going through the strings like see kind of here's all the things that are coming up next. So it'll ask me to translate these things. And then I type that in here. And I make the suggestion, and then it will get committed into the translated repository. And the reason why I kind of was like ooh, you asked me a hard question is that how do you set this up for a doctor repository. That is something I am also trying to learn a little bit more about. We're trying to do that for the DEI team docs I mentioned earlier. I have an easy answer for that because it's it's and Torah the again that build tool doesn't have built in localization out of the box. So we've kind of hacked together our own way of doing translations. So my blade is the front end, but behind the scenes, you know, like actually I think I can open this up to go to pagore, the door docs, Elton, and do I have quick docs what was the repo name. Yeah, quick docs. So if you go here, there is an actual get repository that's on pagore, then it has all the translated strings and you'll see a hey someone did some simplified Chinese translations yesterday for quick docs. The thing is you never you never, you never work with the get repository. It's not meant to be worked on directly. You do everything through weblet. Hacky because behind the scenes, we've got all of these, you know, files that are being committed and then somehow those get rebuilt into docs dot for our project.org. So it's a little confusing, but that's why generally that there's things you want to translate that are already on translate dot for our project or start there. And then if you if there's a repo that you especially want to translate that's not here. So come and find me on matrix, maybe we can try to figure it out together. I hope that answers the question. Yes, thank you very much. Super. Any other questions or comments or anything else about advanced methods and techniques for editing fedora docs. Thanks for hosting me. You're always fun for me to do. Well, I guess in that case, should we go ahead and wrap up here. All right, well, just so folks, you know where to find me. I'm J Flory seven on the fedora matrix home server. You can find me in the, I mean, I guess that you're here in this JC room, you probably already are connected to matrix or using matrix. You can find me in that room. You can also send me a direct message under fedora discussion under the same same username, but matrix is probably the best way to get in touch with me. So just reach out if you have any questions ask in the fedora docs room because at least that way if you have questions anybody who's around can help answer your questions but Yeah, thanks all for your time today and for spending an hour here to talk about all things documentation and hope to see you all next time. Thanks everyone. See you next time.