 Hello, welcome to the Jenkins UI UX Hackfest. This is a big tool, and we have a presentation by Mark about migrating documentation from Jenkins Wiki to Jenkins IO. So Mark will show how to migrate the documentation, what tools you can use, and also you'll talk about the development process for Jenkins IO specifically so that you can create a new documentation if you want. If you have any questions during the session, please just use Zoom 20, and we will be giving you voice permissions so that you can ask your questions during the session. If you want to ask questions offline, we have two charts. One chart is Jenkins CI slash Hackfest. It's our chart for the UI UX Hackfest, and everyone is welcome to participate. Until May 29th, we welcome all contributors to join us and to start improving Jenkins and specifically user documentation for Jenkins. If you're interested, there is a page on Jenkins IO for that. And after the session, we have a documentation seek channel in your way. Again, you can ask any questions. So that's it from me. Mark, would you like to add something? Or should we just proceed with that now? Let's go ahead and show. So what I'd like to do is use some slides to initially frame an outline, and then we can actually go through. So this is the Hackfest, and I'm specifically talking today about how to migrate docs to Jenkins.io. The goal here, the agenda here is to talk about the goals of the migration, why we're doing it, then talk briefly about how to collect, transform, and publish, and then a demo. And the mass of this session today is about that demo. At the end of it, I've got some brief notes on information categories and prioritizing migration efforts. We'd like your questions to come throughout the entire time. All right, don't be shy about asking a question. Don't hold it, don't wait. This is a great excuse to ask questions we intend for this session to be interactive. So questions and feedback, you can ask them through Zoom Q&A. You can ask them to the Hackfest Gitter channel. We also have Hackfest office hours. We just concluded one today. We'll have another session tomorrow and the following day. We had docs office hours on Monday, and we'll have those every Monday for an extended period. You can also ask questions through Gitter or on the mailing lists. So user documentation. What's the fundamental concept here? It is that over the course of the life of the Jenkins project, we have accumulated a lot of very good and very useful content inside the Jenkins Wiki. There are things in there that are very helpful for users, but that because the Wiki has been made read-only, can't be refined and can't be improved. So we have a tool, the Wiki Exporter, which will help us as contributors take content from the Wiki, export it and put it into a place where we can modify them or we can improve them, the Jenkins.io website. We're tracking those with GitHub issues and we've actually gone through a prioritization and an outlining process to get those ready. So our goal here is get content to users so that they can benefit from what we already know and what is already captured in the Wiki. So how do you choose a page to migrate? There are lots of pages in the Wiki and I mean by lots, there are hundreds that were accessed in the last 90 days. Well, we've created GitHub issues for the top 50 most accessed pages. Those top 50 pages have also had the Wiki migration label associated with them in GitHub so that you can see very readily which pages to migrate. There are many more pages than just those top 50, but we thought we'd start with the top 50. Now, if you're interested in some other page, we also have a worksheet that we've used to prioritize all the pages and it shows pages which have not been visited yet for triage. It shows a number of pages which are plug-in pages where we may need to convert the plug-in documentation to code. All of those, a great opportunity for you to help with Jenkins documentation. So it's time for the demo. Let's look at what we do. So how we approach this and why. So I'm gonna put up, first question is how do we choose a page? Okay, so what I did is I didn't wanna collide with anybody else. So I went to the Wiki conversion spreadsheet and found a page that haven't had a GitHub issue assigned to it yet. This is just me being lazy. I could have gone to any one of the GitHub issues and looked at them as well. So I could look here. I could chase through any one of these issues on the GitHub issues page, but I said, I don't wanna have to worry about that. I'm gonna go grab a page that hasn't even had an issue created yet. So I picked how to view Jenkins in your language. Here's the page and here's how it looks in the Wiki. Okay, if we look at this page, we see that let's make it bigger so that we can see. All right, so how to view Jenkins in your language. First, we look at the picture. Oh dear, it's got the name Hudson in it. So it's not a perfect page for sure, but it's got information here that probably will help people, for instance, that Jenkins will display text depending on language of the browser. Now, Oleg has the benefit of not being a native English speaker. Oleg, are there other things on this page where you say, oh, this is completely wrong. We should not even translate it? Well, I can read French, so it's kind of short, it's almost fine with me. Okay, all right. I do not read French either. I speak comfortably Italian, but I was just more thinking of the, we're still able to do locale switching, and therefore this is, yes, and thank you Damien. Of all people, my friend Damien Duport, I'll just comment that no one can read French. Thanks, Damien, we appreciate that. That's really great. Certainly, I cannot speak French. But this page makes an interesting choice of a page that we might translate or might convert from the Wiki page into a page on Jenkins.io. So we pick the page, the from page. Now we need to find the, okay, where should it go? Okay, so let's see, it's probably not installing. Maybe it should go under using, and we say, hey, what if it's using Jenkins with a separate language? Yeah, that might be right. Might be a reasonable place to put it. So we've got using Jenkins using credentials or boarding a build and fingerprints. We might put a new section here which says this is how to use another language. So let's take that as our begin point. So we're going to go from this page, how to view Jenkins in your language, to the using Jenkins page here, and to do that, we need to get something that will let us convert this old page into the new page. So let's go to the Jenkins Wiki exporter. And it's right here. Okay, this tool created by Gavin Mogan using Pandoc will convert a Wiki page at a specific URL into either markdown or ASCII doc. Now, because this one includes an image, I could do ASCII doc or ASCII doc zip. I think for my sake, I've looked at this image, and that image is not one that I actually want to convert because I don't want Hudson in the page. I want it to say Jenkins. So I'm just going to convert to ASCII doc. So I click convert here, and it's going to go read the page. So it read this page, sees the text, and provides me ASCII doc version of the same page. And here's the ASCII doc. Now, that was a pretty easy start. Now I need a place to put it. Okay, so, and we said we were going to put it here using Jenkins. So now I'm going to bring up my handy terminal emulator, sync my repository. So I need to check out a branch. And this is add Jenkins in local language. So I like to name my branches verbosely so that I remember what I'm working on. And now I'm going to take and I need to find that location where I put it. Now you'll notice that on this page, on the using Jenkins page, there is in the bottom left-hand corner, a link which says improve this page. If I click improve this page, it's going to take me right to the page in GitHub. So here is the page in GitHub. And for convenience, it's just given me the path to that page. So hey, that's a help. So improve this page took me right to where I need to go. So if I look at that in my repository, there it is. And now to add a new page in that section, I bring up this file, content.using. I'm going to put in the chapter YAML file. And then I'm going to create a new page, content.book.using. And what did we decide we would call it? It's using local language like that. So this is going to give me the beginnings of where I need to put my pages. So here, using local language, there's a new section of that using page. And now I'm going to go back and copy and paste from my web browser. Let's see, it's right here. This text, oops. So I have a preference that I like one sentence per line when I'm working with ASCII docs. So I'm going to make some changes there. And this, I admitted it's just me. Go ahead Oleg. Does the max have support for preview of ASCII doc? I just wonder. It may. I suspect if I were really deeply into it, it probably would. In my case, I found that the color highlighting is already enough to help me. I suspected it given that it has almost everything and the kitchen sink in it, it probably does. All right. And as here's a good example of one of the things, for instance, we don't really want to refer to the wiki when we're talking about the locale plugin. So we say plugin colon locale like that. And I think if I do a quick check here, I can confirm that the locale plugin is a valid Jenkins plugin. It is. Oh, good. Okay. So if I paste locale here, there's the locale plugin. Yeah. Good. Okay. Well, let's see. Who does maintain that Oleg? Is that you? Yeah. It is. All right. So here I've captured it. Now what I don't have is the ASCII doc headings and headings and footer information. So for that, I usually just go borrow from a neighbor file. So if I borrow from using credentials, I can grab, let's see, here's this section. It looks like that's the usual thing and it starts with a level one head. So if here we put this will be using local language there, we've seemed to have made some progress. Now I personally prefer to put the link colon thing there to remind me that it really absolutely is a link. But I guess it's not strictly required, right Oleg? So where? Here the HTTP. Oh yes, so I think it's not required as long as you use HTTPS or HTTPS. But yeah, my recommendation would be to use link everywhere because there are link plugins, et cetera, which actually look for such syntax. So as a best practice, it's better to look at it. And now I was reminded here, one of the things that I've had to make a change in the past was whenever I find the word slave, I need to be sure and change to agent. And if I find an HTTP URL, I should consider very carefully if that shouldn't be an HTTPS URL. Many of these pages are old enough that they just don't, okay, or in this case I'm checking and the link that it's referencing is not good. It doesn't exist any longer. So that should be taken out. And I've got to find a way to, I'll have to look for that separately after our session here to see, hey, where is the thing that I should refer to instead of that? So these kinds of activities are, what we're doing is we're acknowledging that we're taking a page that may be multiple years old and thus we need to refresh it and be sure that it is still a working page. Nope, so that browser add-on also isn't working. So another, now another step is I should check that this is behaving as appropriate. So let's see, I could bring up my Jenkins instance, check that it works with the locale plugin. I'm not sure if I've even got the locale plugin installed. So let's look if I can find it there. Okay, I haven't installed the locale plugin, so let's install it. And now Oleg, should this one be able to run without a restart or am I going to need to restart my Jenkins instance? It should be able to run. So in Jenkins, you can install new plugins in the most of cases it will work. You can update plugins in the default instance because class unloading is disabled by default. If you really wanted to do dynamic update and don't get off plugins, it would be possible, but it's quite challenging in Java. Now, if I remember correctly, and given that native English speaker here, if I think if I bring up a guest window and configure it with, say, Italian locale, let's see, language locale, showing my lack of expertise here, how do I set my language? Well, let's go look at that site. We could go otherwise. You could force Italian on your Jenkins instance so that your preference to have English in your browser doesn't longer matter. Ah, that's okay. Let's do that. So let me log in. And so I would set the language setting in configure system. Yes, that's how the locale plugin works. So configure system, yeah. I believe I would like to move it to a separate category at some point, but here right now it's here. And if you look for locale plugin. So it will pop up shortly and I'll be able to check it and see. Sorry, my Jenkins instance is a little large. It's the 30 agents that it has and the different ways it does things. It's just heavyweight, come on. And you say it will appear here. Oh, there it is, default language. Good, okay. So once the page is... I'm not sure what's going on with your instance, but it takes a while. That's okay. Are you sure you're not running on Raspberry Pi? I am confident, although that's a very valid question because I have several. My Raspberry Pi is just an agent right now, not a master. There we go. Okay, so here we have it. And if we scroll down, locale was... Oh, I have to search, don't I? There we go, default language. And now this is one where I can just type in the... I love having help. Okay, so locale. So it's probably it underscore it.utf8. Even without utf8 it should work. Ah, right, okay. So Italian has spoken in Italy. Yeah, and you also need to set a checkbox below, ignore browser preferences. Oh, right, because otherwise... Yeah, otherwise it won't work. This is how we tend to configure it on our instances because we prefer to retain English everywhere. But for example, here we have it in our interface. And there we have it, nuovo elemento, utenti, cronologia, compilazioni. Yes, this feels like Italian, wonderful. Okay, so we've seen that, okay, that's how it... Now I probably want to take a screenshot of this so that let's shrink it a little because I need a picture. And this picture, let's take it at a reasonable size, say 1152. And let's take a screenshot that I can then embed. Oh, my poor windows is very busy. So take a screenshot and there we have it. So that picture I could now upload and put it into my pull request as an example image. So instead of this one, I would replace it with, and now I have to always look up the image syntax. Let's find it a good example of an image somewhere. Here we go, that's a sample. So it looks like something like that. So an image markup might be like that. And instead, I would want to put the image into another location like using and I would call it something like Italian Jenkins. There is one thing to keep in mind that your currently operating code is user documentation and user documentation has a different approach for 100 images. Oh, good. It usually puts everything into resources but it was a, it's basically historical thing after introducing the Jenkins user handbook because the most of user documentation originally came from there. So if you open other pages in the same folder, you may see that they define resources and images differently from the rest of the Jenkins. Well, I should follow their pattern. So let's use that as a way to follow their pattern just to be healthy. Okay, so this one doesn't, this may be the first image I'm inserting but I think you had said that there are other examples where we've got it in the resources. So it would be in this directory, resources. Well, you can try it, yeah, book resources and everything goes there. And there are macros defining the remote location in the beginning of Asia's Kedok. Good, okay. So I could grab an example from the managing section, for instance, from and use its macros that define where to locate that image. Good, okay, let's do that because I like putting them, I wanna be consistent with the other things in this document. So what I do is I make a directory here, right? Does that make sense, Oleg? That now I have got a directory at the same level as managing, I've got one for using and I'll put my picture there. It's totally reasonable. I'm not sure how we handled other pull requests and yeah, I'd rather mention it for other contributors because yeah, for me, whatever works, you can, we don't really build the user handbook right now. We could, but yeah, right now if you use common approach by putting the images to slash images, I think it would be perfectly fine. So it's okay either, that's a good point. I don't have strong opinion. Great, okay. Since you're a documentation officer, you basically can make a call how we should do that. And I am a very simple soul. I'll take things, I tend to follow existing patterns where I can. All right, so we need a using directory and now I've gotta put that. Now I admit I'm running in a little bit different environment because I do my development work on a Linux box but I'm actually seated at a Windows computer. This terminal emulator I'm running is on my Windows computer. And so I've got to download that image that I just took the snapshot of and put it into a place where I can upload it. So let's save this and bring up handy dandy git. Your experience will be different because you'll get your annotations, you'll get your pictures captured other ways. You may not be running on Windows, that's up to you. See, this was Jenkins in Italian.png. Okay, so it's now over on my Linux computer. And, okay, so there's the file. Let's see, oh no, I want it one level further down. So it needs to go here into using. And so in using, I've got Jenkins in Italian.png. And Oleg, you had indicated that I should be able to find that macro in my file. Yeah, so yeah, this, I think in the beginning. Yeah, so if I look in the managing thing, this thing, oh, it's already, you say it was already there? No, I don't see. Maybe it's actually not required for images in this section. So if you scroll down, you can see how the images are used. But yeah, I don't see overwrite of the relative pass for images here. So maybe they still have URLs from root. Okay. So whatever works. Great, yeah, so here's one that says, ah, okay, here's an example in plugins.adoc. And it's got, there it is. I think this is what you're referring to, isn't it? Oleg, this if def there? Yes. Great, so let me copy that. I can borrow readily. I just put it right there. And then the way I refer to it is by saying using slash and then the image file name. So it would be using and it's a relative. I like that. And it was Jenkins in Italian. And I think that's already given us a beginning. Now, if I do a quick check, it says I haven't added that yet. And I've got to add the resource. This is where I need my shell again. Now I did not optimize that image. Oleg, should I have attempted to optimize that image? Is that one of those? You could, but I'm not sure. What did you use to take screenshot? If it's just pretty good. Yeah, I use SNP and sketch by Microsoft. And it's generally not been, when I've optimized those images, it hasn't been a huge reduction. So I think it's reasonably efficient. Okay, just keep it. So, and so I think I've got everything I want. I think I'm ready to try it out. So what I've done is I've added an image, I've added an entry to the chapter, and I've added in the page for using local language. Let's do a compile. So let's run it. And I'm just gonna do it with make run. So the make targets are described in the contributing file for the Jenkins.io repository. And you could do this make run from a shell. You could do it from your IDE. Wherever you prefer to do it is fine. In my case, I happen to be sitting inside this editor. I could also do it from a terminal window. And so what it's going to do is it's going to start up a Docker image, read the files from my file system and start a running web browser or a running web server on my computer on port 4242. So you'll see it right here. Now I could access that if I was sitting on that Linux computer or in my case, I start a tunnel so that I can access it from my Windows computer. And now let's bring it up and see what it looks like. So now this is where the danger of online demos or live demos comes vividly through, right? Because you'd expect something could go catastrophically wrong here. So here's the page documentation and I changed something in the user guide. So I was in using Jenkins and I added using local language. There it is. And here's the page. Now that image is awfully big but probably workable. I may need to resize it. It doesn't really have anything particularly personal in it but from a strategy, it may need to be that I have to change it to be simpler, cleaner, less about, less mention of mark weight, less mention of individual specifics. But it is really a Jenkins page converted from the wiki to Jenkins.io. Let's look at the... So where are we here? Here it is running. Now if I needed to make a change, let's say I did. So let's make this text big enough to read. Let's say I wanted to edit something in that file. Oh, I've made some mistake. For instance, what's a good choice? I don't like the word so. It detects the language of your browser. And I made that change. The running web browser detected that change or the running web server detected that change. Now if I go back to that page and I reload that page, my change is there active. So I didn't have to stop the compilation process. I didn't have to do anything other than modify the file. Is it always perfect that way? No, but many times it will work just great for you that way. I think I found cases where when I added a new file it might not detect it and I'd have to restart it. Oleg, were there other points that you'd like to highlight here on the experience using make run and looking at the site? Well, nothing specific. So if you use Linux, it will be quite straightforward. If you use Docker format, it's also quite straightforward if you'll just run. For Windows, it requires some experiments and if you want to contribute and use Windows, please contact me in the chat. I will send some links. It's playing how to do that or maybe even a document that on the Genki site contributing guideline. And actually for all the information Mark presented today and for all other details, just take a look at the contributing guidelines and the repository because they include a lot of useful information. Thanks, Oleg. Yeah, thank you. So when I'd reached this point, I could now contribute, create a pull request. And so for me, I like the hub command. I could use the web user interface to create the pull request. Oleg, are you okay if I use hub instead? Just as a show a different way to do it, I could create the pull request just by committing, I have to commit the changes here no matter what, right? So let's commit the changes and let's migrate using local language from Wiki. Now I push that and I'm lazy. I like to make git tell me what the command is I should put in. So I've pushed that to my remote branch. Now, if I go look at that, and it gives me a nice hyperlink there. If I go look at that, I can see right here that it's ready to go. And I could finish this pull request right here just by clicking the create pull request button. Now, Oleg, if I remember right, there were some things that might help if I added them here. Should I assign this to a project now? Is it okay if I do not? It's perfectly not to do that because if you, for example, for common contributors, there is no permission. Ah, got it. Yeah, we have a triage team which processes the this pull request. One of contributors will process that and assign it to a proper project. Very good, okay. So then I'm just gonna go ahead and do it here. This is what, oh, ah, yes. And this is the checkbox that I saw you. So yesterday in our docs office hours, we talked about this particular checkbox. Allow edits by maintainers. This will allow other maintainers of the project to actually make changes to my pull request. It's an option that allows me a little bit of extra flexibility. If I said, no, I want complete control of my, I could uncheck that. Good, I finally see that. Okay, pull request created. And now it reviewing is assigned to copy editors, the documentation label was automatically created. Now I did this backwards. I could, I could now go create an issue in Jenkins.io to track it and put it there locally. Oleg, are you okay if I do that, admitting that I'm going backwards? Yeah, I'm fine with that. So we have templates here on Jenkins.io for issues. This wiki migration template makes it easy for me to say, yeah, I was migrating a wiki page. And so I'm going to migrate from using local language to Jenkins.io. And what we do is we place the target page into that and then we put the source page. Any other hints that you wanted to offer here at Oleg in terms of effective use of GitHub issues? No, I think so. The idea here is just make it as simple as possible. So you reported the issue if you see some pitfalls, for example, if you see that screenshots are several dated and just put it so that Homaver takes this issue, know about that, but yeah, that's it. Great, thank you. And now after this pull request is approved and merged, I can do one additional thing which would really help, which is create a submit a redirect request to cause the original wiki page to automatically redirect to the new page on Jenkins.io that can help search engine optimization. It helps people get to accurate information more quickly. Yeah, because right now these pages again, mark the transition for heavily accessed page. And it means that it will be staying in Google search for years if you don't set up redirect. Maybe not years, but definitely it will take a while till Jenkins users start discovering new content. We've definitely seen benefits to using these redirects in that it helps people find the information sooner and we really want to help the users. So I'm gonna go ahead and submit this. Oh, let's see, submit this issue now. I probably have permission, but most users will not have permission to link to the pull request or will they? See, I know what my permissions are. Yeah, you can create an issue and you can just reference it from a comment basically with the same result. Oh, I could. So I could have referenced it here by saying implement or pull request is number and then I would put in that number, which is 335, oh, there it is, 3356, like that. Good, thank you. I've sort of droned on on this demo. Are there other things that we think that should be are crucial that we should talk to? Now just don't forget to report it on the HACFEST repository. Oh, okay. Actually, well, do you mind if we do that now because that's when I need some practice on Oleg? So that's why... If it just takes a minute. So if you don't mind, it will be much appreciated. Well, and for me, I am not nearly well enough practiced in it. So what Oleg was just alluding to is that we've got this really cool GitHub repository that tracks contributions to this week's HACFEST. And we're going to use that information to send out swag, et cetera. So now that HACFEST repository is here, right? Jenkins CI slash UI dash UX HACFEST. I think this is the one, right, Oleg? Yes. Okay, and now what I do here is I just create a new pull request. No, new issue. Oh, I created a new issue. Oh, thank you. Okay, so I go here, so go to the issues tab and I create a new issue and it will offer me a template, which thing I'm working on. So I was working on documentation. So I'm going to click documentation and hit the get started button. And this was my great using local language to Jenkins.io. Okay, so link related pull requests. So it would be, there's the pull request. I do care if it has a link to the issue, pull request is enough. Oh, whatever it looks. Okay, great. And this one doesn't, actually, it's got to have a screenshot. We have to drag in a screenshot. So I'm going to pull in a screenshot from here. Jenkins in Italian. Very lovely. No, you don't have to do screenshots, but I like pictures. And then I just submit new issue. Now what's the processing that happens after this, Oleg? Is this something that I need to take another step on now? No, so it will be processed by one of the organizers, we use spots. So if you, so basically you just process this reports at them and for example, for that we use tool called all contributors. So if you go to the root page of this repository mark, then you can see all contributors who have already reported these contributions. So, yeah. So yeah, not everybody submits it immediately. We know about the digestions who haven't reported the contributions yet, but we will get there. And if you do something, please make sure to report that, even if it's something minor because any contribution matters. Excellent. So, but it was that easy. All I did was I submitted an issue to this UI UX hack fest and everything else administrators and bots will take care of going the rest of the way. Bots and administrators because bots are doing the most of the work work. Okay. All right, I like that even better. Bots and administrators, but who's doing more work first? All right. So I can go back to my terminal window. It's probably time to turn off that and I don't really need to keep running that. Now I had a couple of other items before we conclude the session today. Oleg, were there any questions that have arrived? I haven't seen any Q and A. I don't know, questions. If somebody has any questions, please ask in Zoom Q and A. You just ask for whispered missions and we can discuss anything. All right. So one of the questions might be, hey, how do I know where to put things? And for me, the first, where do I put things? You're welcome to just ask in the docs getter channel. You're welcome to do your own investigation and propose a place. You're welcome to suggest it in your poll requests. And if as poll review, as poll request reviewers, we don't feel like you got the right place, we're comfortable telling you, hey, could you put it here instead? It's not a huge bunch of work to put it in a different place after starting in one location. Now we've found that there are, at least for me, there are some general categories. There's the using Jenkins, administering Jenkins. We've got two GitHub projects tracking those where we have a longer term vision to create two separate volumes of information, one for using and one for administering. Right now they're sort of commingled. And we're tracking those in these GitHub projects that are linked here. So let's see if I can find those on, here it is. So this is one of the GitHub projects and they help us see, hey, how are we doing in making progress towards getting content into the administrator guide. There's also the actual chapter on Jenkins.io where you can go read the information and see what it has to say like, let's see this one maybe. Yeah, where this has, you can just go read it and see what the pages contain. I think that that categorization will help you. If you find a question, go ahead and just ask. Now, in terms of prioritizing the migration, what should you work on? I think first choices work on things that you find personally interesting. If you've been involved with something, you're much more likely, if you've used it before, you're much more likely to understand what should be said and shouldn't be said, make corrections, add value. If you say, oh, I haven't worked on any of those things, we have the top 50 most actively read pages as GitHub issues, pick one of those. If none of those look like they're interesting, you can actually go all the way to the Wiki conversion sheet that has 250. See if I can find it, 250 or more pages. Ah, yes, here it is. Things, these need to be triaged. Someone needs to look at each page and say, this page I think should go here. This page should go here and you can propose changes to this sheet. So welcome to propose any one of those, prioritize and help us in any way you can. That is a question from Block. Yes. Thank you very much, Alec, for allowing me to ask. Thank you, Mark, for providing this wonderful webinar. I have a question about kind of process about creating these issues and pull requests. For instance, I'm working on documentation after we created an issue or pull request to modify the documentation. Do we need to go to this HackFest UI site to create another issue, tracking our issue in the documentation in case we already created initial issue? Yes, I'm talking about exactly this site. My understanding is just the database or we need to track any issue created in documentation again in this site as well. There is no need to track any issue, though it would be nice if you could report the chunks of work. For example, if you spend some time on reviewing particular pages on creating integration pages, for example, once a day, submit an issue with summary of your work. Why it's useful because we use this information to quickly assemble reports for the HackFest. So we will be posting the first reports tomorrow. And if we have this data, it will take much less time for us. But yeah, if you don't submit anything, be sure we will still find you using GitHub queries. It will just take a bit more time for us. And I like that heuristic. If I've worked on something for the HackFest in a particular day, that's a good excuse to submit an issue to this repository for that day. Once a day is probably good enough, Oleg? Yeah, whatever happens works for you. Okay, great. Good questions, Vlad. Thank you. Thank you. So Oleg, I think that covered the topics that I was most focused on. I hope people enjoy helping us and we're very grateful for the help to convert the documentation, to make the documentation steadily better and better. Thanks for your presentation, Mark. Are there any other questions before we close the recording? No questions. So yeah, if you want to ask anything, please ask in the documentation, seek GitHub channel. And we always have someone around and we will do our best to help you proceed. Thanks, Saul. Thank you, everyone. Have a great time and we'll see you as things go on. Yeah, bye.