 So welcome everyone. This is the Jenkins online meetup. It's the 14th of October and we're celebrating Hacktoberfest this month. This is the Docs and More presentation. We're going to share with you how you can contribute to Jenkins as part of Hacktoberfest. Hacktoberfest is a great experience and the Jenkins community has used Hacktoberfest for a number of years as a way to help people as they want to contribute to Jenkins and to help open source. So let's talk about who our presenters are today. First, we've got Oleg Nanashev. Oleg is based in Switzerland. It's an international community today presenting. He's a Jenkins contributor. He's a member of the Jenkins governing board. He's been involved with Jenkins for many, many years and has contributed significantly in many, many different ways. I'm Mark Waite. I'm based in Colorado in the United States. I've been involved in Jenkins for a number of years as well. We've also got Jonathan Morais with us from Brazil. Jonathan is a contributor to the documentation special interest group with interest in code and how to do effective documentation as code. He's been a great help in the doc special interest group. We're so grateful for him. We've also got Vlad Silverman joining us. Vlad is here from California and we're looking forward to his presentation as well. It's great to have all of our presenters here. We love Hacktoberfest and are grateful for it. It's a good thing for us. It's a good thing for you. Thanks for being willing to help us. Now, today's agenda, we're going to have me do these brief intros and then Oleg's going to share several different ways that you can contribute to Jenkins in Hacktoberfest. Jonathan is going to then highlight some of the things we did to prepare for Hacktoberfest so that you would have a good experience. After that, Vlad will talk about how to build the Jenkins site locally so that you can do documentation, test, and evaluation on your own computer. And I've got some session ready to show how you could do plug-in documentation migration from the Wiki to GitHub. And at the end, we'll do question and answer. Now, what we'd like to do is encourage you to ask your questions using the webinar Q&A system. That helps us so that we can answer questions. We'll choose to answer them live or answer them in chat. We're open to your questions, open to suggestions and ideas. And at the conclusion of our session, we'll stop the recording and then invite you to talk with us directly. Oleg, I think we're ready for you. Okay, let's begin. So did we go through this slide already? Okay, let me just cover it. So, yeah, Hacktoberfest 2020 is quite an exceptional year because this year, the vast majority of Hacktoberfest happens online due to obvious reasons. Even before Hacktoberfest was a worldwide event, during one month, there were hundreds of various events happening across the world. And everyone was able to contribute to MoQ as well. This year, the main focus is on remote. And basically, the framework remains the same. So you can submit focal requests. And after that, you get a T-shirt. Or now, you can plant a tree, or somebody plants a tree for you if you're correct. So it's your choice. But the idea is quite simple. So you can just click a button, start hacking, register by signing up with your GitHub account. In my case, I'm already logged into GitHub. So for me to show my profile, I guess. But if you go here for you, it will show the sign up form where you can register. And after that, you can start contributing. Basically, that's it. There is some specifics introduced this year. We will talk about it later. Okay. Let's talk about the Jenkins project specifically. So Jenkins, as many other projects, participates in Hacktoberfest. We started participating actively in 2016 when we published a special page for Hacktoberfest when we started preparing newcomer friendly issues and promoting the event. Since the project has been successfully participating in Hacktoberfest, you've got many contributors joining the project and the community during the Hacktoberfest. We invite everyone to participate. Your experience with Jenkins doesn't matter. There is a lot of newcomer friendly issues. There is a lot of opportunities focused not only on code or documentation, but on many other activities. Basically, anything you can submit as a pull request qualifies for Hacktoberfest. So this year, we are happy to introduce a number of featured projects and also a lot of issues which have been prepared before the event. And we will talk about them today. Again, anything that counts. So Hacktoberfest is built around GitHub. Any repository which is public on GitHub is eligible for Hacktoberfest if it's configured properly. So what it means that all the code, documentation, and also many SCOTAC instances, for example, infrastructures, code documentation, SCOTAC, and many other areas which you can represent as code and find on GitHub are also eligible for Hacktoberfest. There is no specific differentiation for that. In the case of the Jenkins project, almost everything is stored in GitHub repositories. So basically all the content we have, design, artwork, of course, all the code, test sheets, et cetera, all of that is available as code, and hence you can contribute. Many perceive Jenkins as a Java project. And yes, the most of Jenkins is written in Java, but actually it's not only about Java. There is a lot of other technologies you could work on. If you're interested, last year, together with Mark, we did a presentation about contributing to Jenkins. And if you want to, you can go to that. It's probably, I can share the link in the chat later. And there you can find a lot of information about what actually interests you. And for Jenkins, it's a vast ecosystem with hundreds of plugins, with many infrastructure repositories, basically for many areas you can find existing projects. So whether you are a Java developer, a Go developer, if you want to try front-end, or if you want to write something, you can find something interesting for you. And if you're interested in a particular technology, just contact us and we will be able to provide a few examples. Today, we are talking mostly about the documentation. So let's go quickly to the documentation part. Okay. So yeah, you can find some examples here in these slides. Java script, go along, many other languages. And yeah, today we talk about the documentation. So for documentation, in the Jenkins project, we use Markdown and ask KeyDoc. We have a lot of repositories using Markdown as a bit hard to ever mark down as documentation language. The Jenkins website is largely written in AskDoc. Today, we will cover both of the technologies. So Vlad and Jonathan will talk about AskDoc-based documentation, Mark will talk about Markdown-based documentation. So yeah, we will cover that. In addition to these formats, you also have a lot of embedded documentation, all components, and there you can find a lot in text, the language, the mail, and other languages. So again, any repository can be a good fit. So for this tutorial, let's finish with the main presentation so that we have more time for Q&A later. Okay, why to contribute? I mentioned multiple times that any repository would qualify. And yes, that's true. But at the same time, especially for newcomer contributors, it's important to have clear guidelines, issues, et cetera. And we did our homework before the hardcover first started. And we prepared a number of newcomer-friendly projects to which you could contribute. And all these projects are considered to be very important to the Jenkins project and the community. Many of them are represented on the public Jenkins roadmap. So it's not like we found some areas where there are newcomer-friendly tickets by contributing to these projects. You actually contribute to the Jenkins project goals. And here are some examples. So there is Jenkins website with a lot of ongoing communication improvements and the restructuring. There is Jenkins Core, which is basically a foundation of any Jenkins instance running. Then there is a plugin site, which lists information and documentation for all the plugins we provide from the Jenkins project. There is Jenkins file runner, portable pass engine. There are a few plugins listed, for example, Prometheus plugin. Actually, we don't have any other plugins listed here. It's each of the projects. There are other plugins. You can come up with the issues. We will talk about how to find them later. Also, we invite everyone to participate in terminology now. So we are coming up with agent, controller terminology, and other areas. There is a lot of people requests you can do there. It helps the project. Also, if you're a designer, in Jenkins, there are multiple ways to just improve the look and feel. For example, you can just contribute artwork, which can be used in web interfaces on the Jenkins website, on community projects. Also, if you want to improve the existing QIs, you can contribute to themes. For example, there is a recent dark theme for Jenkins, which had been created several months ago. And there are other themes, or you could just contribute to Jenkins UI. All of that is possible. And yeah, what else do we have as featured projects? If you're a fan of Prometheus, we have recently moved Jenkins help charts to the Jenkins organization. So now it's a part of the official Jenkins repository. And we invite everyone to contribute to the version 3.0 of these charts. There is a lot of different activities and issues available. And also, there is ongoing projects for plugin documentation integration. It has been available even during the previous hardware first. But yeah, there are still hundreds of plugins to move. So we will appreciate the contributions there. So all these projects are not just tables. You can find that for every project we have published here, we have clear contributing guidelines. Instead of good first issues, you start working on and also list of other open issues and the documentation which may help you to get started. So you can take any project which is interesting to you and just start working on that. For new comment contributors, it would be the recommendation just to start from one of these projects. If you want to find more, as I said, not everything is listed as featured projects. We also have a number of issue queries where you can find issues such as hardware first. So for example, in Jenkins JIRA, it's the old box record for the project, you can find just three issues marked for hardware first. But likely we will need to do some stuff there. But okay, if you go to GitHub queries, so many new components, now use GitHub as the main issue record here, you can find more than 50 issues focusing on different areas. So you can see that there are some plugins which haven't been listed. For example, Azure Key Vault, Slack plugin, configuration as code plugin, Tecton client, et cetera, et cetera. So you can find more projects where you can contribute here. And also, if it's not enough, there are also common newcomer friendly issues which haven't been sorted specifically for hardware first. So here, yes, we have several hundred issues and even more good first issues on GitHub. All these issues should provide enough information about how to get started and how to contribute. So take a look at them. And again, we will appreciate the contributions of the service. Did we get any questions so far? We don't have any questions that have arrived yet. Now, there is one table that I've enjoyed that is the table of fresh issues for, or of newcomer friendly issues on JIRA that shows things like the Git client plugin has a newcomer friendly issue to help me translate tests from JUnit 3 to JUnit 4. So you had noted all like individual plugins may not say, oh, I'm a featured plugin, but they are still very welcoming to contributions on these newcomer friendly issues. Right. So we have hundreds of active repositories in our organizations. And if you contribute somewhere, you can get initial feedback and reviews. And even if you don't get feedback immediately, it's still not a blocker from contributing there because we have a process which still allows us to mark these contributions for hardware first as eligible requests. Okay, let's actually talk about that. Okay, so let's get started. If you want to get started with hardware first, again, you register on the website, as we discussed before, then we recommend to join our Gitter channel. This is a channel which you can use for any kind of Q&A. So if you have any questions, if you are stuck, if there are some organizational problems you would like to start out, for example, you don't get reviews, etc. Please let us know here and we will process it and help you there. Basically, that's it. You start contributing. For contributing, again, any pull request to any GitHub repository comes, but this year, there were some changes in the program due to which traffic of spam pull request coming to other organizations. So, hardware first team modified the process and now it's opting for hardware first contributors. For that, we added additional process so that when you create a pull request, we need to know that it's related to hardware first so that the hardware first team can market properly as hardware first accepted pull request so that it counts towards your hardware first goals. I'll show you how this process works. Again, let's just take a look at our featured projects. I want to do something quick but at the same time useful to the project and I think that terminology cleanup could be a good example. So here you can see that there is a link to Epic Voyaging Terminology cleanup is open issues and contributor guidance. So, we can start from here and here there are a number of newcomer-friendly issues. Let's just launch this GitHub query. So, basically, it searches across JNPCI GitHub organization and it looks for usages of slave terminology. By default, we want to clean up everything. Still, there are some scopes. So, for example, here you can see that some of the usages are related to code and to API. So, these parts are quite challenging but there are also documentation parts. So, for example, I can just filter by markdown and it will show a lot of documentation. So, here you can just browse through that and we can find a component which we would like to update. So, for example, there is a copy to slave plugin. So, let's take a look at that and see what's in the current state. So, there is a short page here which basically summarizes what's the plugin about and there is also a wiki page and I guess wiki page hasn't been getting created to GitHub. So, it's something Mark will be talking about later. So, yeah, this is the actual documentation. But let's imagine that we want to clean up this repository because it's valid request and here let's take a look what's the current name of the plugin. So, the current name is copy to slave. We can assume that it should be renamed to copy to agent. Now, let's try to create a pull request for that. Again, I will be just using the GitHub web interface. So, no IDE needed, nothing except your GitHub account. So, here you basically look for all the usages of slave in the main page and you can just replace all of them. So, this one we can attach it because this is wiki. This one, I guess we can just remove it because it's 2020, the source code. So, it's now only on GitHub. So, we cleaned up some references. So, what else we can do here, for example. Okay, let's keep it as is. We can update it more, but we wanted to just rename this. So, this is what you're able to do for now. Here we can say that clean up slave references. Okay, so this is my first patch. I just submitted and create pull request automatically. So, here you need to mark it for October 1st so that we can discover it on the organization level. So, I just put October 1st flag and I guess that's it. Okay. So, again, read me. I created this pull request. Basically, this is already a contribution which my help users is in this page and we can assume that it's a valid October 1st contribution. So, what will happen? It's not you doing that. It's we put October 1st accepted pull request so that the pull request becomes eligible for October 1st and that's it. So, we have created our first pull request which does something useful. Obviously, you can find much more examples for that in your plugins. I just wanted to show a concept of how you could do that. Okay. Let's see. There are more ways to contribute. We talked about featured projects. We talked about queries, but actually we are not limited to that. There is a page called Jenkins.io slash participate. It integrates information about always to contribute to the project and if you are looking for more opportunities, please refer to this page. So, there is guidance, for example, for contributing code, contributing documentation where you can find more references, more queries references to other ongoing projects. So, for example, in the documentation seek, there is number of projects related to the Jenkins documentation and you can find it here. It's also from the page somewhere. So, for example, Jenkins on Kubernetes, for insight integration, for in documentation, user guide for work, et cetera. So, there are more areas where you can contribute to and you can explore these guidelines to find these projects. Or you can just ask us in the GitHub chat and we will be happy to help you. Okay. More advanced projects. Basically, any pull request to any Jenkins GitHub organization accounts. Also, you can contribute to upstream projects. Jenkins uses hundreds of different upstream projects. Honorable mention Apache Maven, including tools. Also, many other Apache projects we use in our code base. Basically, for many other projects, which are part of the Java system. Also, if you want to develop .NET code, we don't have .NET code right inside the Jenkins organization, but there are projects we use like Windows Service Striper for managing Windows services. So, you can take a look at that. You can also work on your own repositories. For example, just created demos for Jenkins to some more experiments. For example, this Jenkins configuration is code, this Helm charts, this Jenkins Kubernetes separator, and these other new technologies available in the Jenkins project. You can mark these repositories for hardware first. You can make them discoverable for others so that they potentially help other users. Of course, you can also patch your Jenkins pipelines, especially if they're in open source projects. In addition to that, there are CDF projects. You can also take a look at them. So, Jenkins delivery foundation will participate in October test as well. And if you want to find more information, here are links for all CDF projects. So, here you can find the guidance, etc. for all of them. Okay, that's it from me. And if you have any questions, please ask in the chat. You'll answer them. I think we should slowly move on so that we can go through the entire agenda. Thank you, Oleg. Jonathan, you ready? Let's see, Oleg, I think you need to continue sharing your screen so that the slides are visible. That's great. Yeah, I'm ready. Okay, let me do that. Yes, please, Jonathan, go ahead. No, okay, okay. So guys, hi everyone. I'm Jonathan, I'm a software developer, and I love when my daily tasks can run for the Intel, so because you're a Jenkins, and I have been a volunteer at Jenkins since early 2020. So I'm quite new here, too, as I started just a few times ago. And the idea today to show you how we prepare everything to offer you a better experience on a hacksaw effect. So first of everything, I would like to say thank you for your help. We already see several PRs and a lot of new members joined to our community this month. And those PRs really help us improve our documentation and offer a better experience to our members and community, too. Okay, so just to show you a big picture about our preparation, we'll show you some charts. So as you can see the yellow, big yellow slides of the chart show all issues we have to work early August. Okay, so we mark and others map all issues, all pages from the older week we have, and how they are important by their own visit page. Okay, so once map it, we work hard to open all issues for GitHub, so can move for the next chart, please. So in the next chart, you will see the difference. Hello, Mark. Oleg, I think you need to go back one. Sorry, Jonathan, I think Oleg, you need to go back one. This is, I don't know, you were right, August 2020, you were correct. Sorry, next slide was where we're going. There we go. Oh, okay. So now in the new chart, you can see we work to finish some issues. So the green one show every issues we already migrate for the new site, the jigs.io, and the orange slide shows how many available issues we have. So 5,000, so now we have almost 150 issues to work on it, maybe less now because I already closed on them because they are October fast. But the most important is almost 50 items are set as good first issue. So there is two important points here. The good first issue is where you should start to contribute to Jenkins, okay? So if you need to learn how github works, so if you need to learn about the process and you want to know how Jenkins works and how to get best for the software, and the documentation is the best start point to you, okay? So for that reason, I start work on Jenkins documentation too. I'm a software developer. I can work for another plugin's development and other things, but I choose the documentation because yes, okay? It's a good way to take back for community for everything documentation we already see on the internet. So it's good to you. It's a good place to stay and to start, okay? So just go to github, so to go to the main poster of Jenkins, go to Jenkins.io, click on issues tab, okay? So there you can see all issues we have available to work and click on the blue one. Inside then it's right. Good first issue to start, okay? So here in that slide we have a print from a software issue, okay? So once you click on issue to set U.S. work on them, you just write a comment. So just say on the comment I work on it, I would like to work, okay? So there is a lot of good content there. So when you pick an issue, yeah, all you need to start work with all that, but if you need some more assistance, feel free to ask for help. We stay there to help you, okay? So inside this each issue has a video required by Mark where you can find how to work on documentation and how to be great at page from the old side to new ones, okay? There is a lot of other information too, so take time to, your time to read on them, if you find impressions, just send them. So the issues, good first one, it's your start point, okay? Another important thing to know is the another 100 issues, it's more complex, but not so complex at all. So once you watch the video inside the issue, you are ready to work on Jenkins documentation and migrate the page. The only difference between the first good first issue, a normal issue, it's because some of our content, it's not up to date. So we need to rewrite the documentation, update the content. So in that moment, you will learn more about Jenkins and contribute with communities, okay? So to do that, you need to set your environment and this event, Vlad will show you the next session, how to set your environment, how to create your first PR and how work in Jenkins documentation. So everything you need to know to start, Vlad will show to you. Well, so at the end, I hope you all reach out new four PRs to earn your t-shirts or even better to offer to plan a new three on forward. It's important to stay alert about nature and a lot of things related. As I said, I'm from Brazil, so here we have fentanyl, we have Amazonia and I can tell you guys we need more trees to stay and help world to our children, okay? So thank you guys, thank you for your time, thank you for your participation. And I'm done here, thank you, it's on you now. Thanks very much, Jonathan, that's wonderful. And yes, the plea for more trees is a good plea, that's the right thing to do. Thank you, thank you. I think we're ready to now switch to the next presentation or, Oleg, were there other items you wanted to highlight here as we were as Jonathan. I just wanted to briefly highlight the contributing guide to answer the question in the chat. So the most of information we present today is already available as contributing guidelines. For example, for Jenkins website that is contributing a dog inside the repository. And here you can find all information about how to contribute, how to address particular use cases, for example, maybe writing the documentation, this is what Jonathan was referencing. But if you want to create a new one, if you want to create a tutorial or write a blog post, you can also find the information here. And same for development needs. So a lot will present how to do it. But if you want to have more information, you can also find them on this page. I find it particularly nice that I can actually read the source code for those adoc files. If I've got a question about how to do something, I can use them as a pattern to do something else. So excellent. I think we're ready next for Vlad. Thank you very much, Mark, for letting me talk. Let me share my screen first. Let me know if you can see my screen. We can. Thanks very much. Okay. Well, let me show, well, this is our visual code. This is IDE, one of the popular IDs, which people are using. But nothing that I will show will depend on this IDE. So nothing is dependent on this specific development environment. And if you have just terminal, if you have just Windows command screen, you feel free to use this. It is just convenient to have in one development environment editor and terminal thing. So for my own benefits, I prepared this read file, which is in Markdown syntax. And it is just convenient for me not to forget everything that I would like to talk to you about. And it is possible to view this like in the web. Well, the first thing that you want to do when started contributing, of course, and then talking about just contributing to documentation, you go to our documentation website, which is Jenkins.io and Jenkins Infra organization. And you look for issues. And, well, I specifically for this demonstration picked up one of the issues which created myself and it is fixed terminology. One of the projects which Oleg highlighted in his presentation, but it regarding only the documentation part. So you click on this issue and it describes exactly what needs to be done. It needs to change the white list to allow list. This is new terminology that we are using in developer section of documentation. And it presents all files that needs to be changed. Links to all this previous presentations. You can go through this and browse them as well. And it mentions very important feature thing. It is accepted that documentation change may proceed the user interface or code changes. So you can change documentation without worrying that the code is not changed yet because as, well, some people may know that code a little bit more difficult to change that documentation sometimes. So let's watch it. In case if you hadn't done this before, let me shift my screen. First thing is you need to fork, of course. If you hadn't done this before, fork this repository too. I had forked this before. So here is my fork. And after that, after you fork this, you just need to clone this documentation to your own repository. This is the copy button. You just copy this and you can use different methods protocol. Right now it is available using GitHub CLI, which GitHub recently reviewed, but just SSH is also possible to use. And you copy this, copy this string. And after that, you just, let me see. You just use Git or clone and after that, just copy and place this copy, copy SSH command. And I had done this before, so I'm just not doing this. And after that, you CD to Jenkins.io. And this is the documentation website. Well, I'm doing exactly what is written in this freebie file, which in case if people want, I can share this, but this is specific to this, to fix this issue regarding terminology. Now, what is important, and this is usually what I'm doing, when I'm looking at this, I would like to be in sync with the master branch, my own repository. And this branch is even with Jenkins in from master, in case if it is not, tell there are two simple commands, which I organized in like Git sync shell script, which allow you to make sync up with the master repository very, very easy. And after that, what you want to do is just let me see in which branch I am. Okay, where the master branch. And so what we can do, we can do Git checkout minus B and well, fix dev doc. And you can like put any name for your new branch and just try to match what you are going to do, so people will understand, easier to understand for those who will review your contribution, basically, and your fix. And minus B means that you are just creating right now into a copy in case if you have, you just do checkout. So we're switched already to this new branch and we're already there. Now, we go replace whitelist with allow list for every file in the selected set of files. And of course, I opened all these files in my editor. And here they are. And again, just to make sure that you understand we're taking all these files from from this list, because this is very detailed written actually issue. Sometimes it is not so detailed. Sometimes it is like, yeah, but it depends. So we're going to the specific files that start from this like last last issue. So we just do search for whitelist and we'll try to replace it with allow list, allow list. And you see there is only one thing which we need to do. We just click anti it is replaced. And another thing allow list it is modified here will go to another file and just do the same. It is two on occurrences of this just replace them both and for this one the place and it is modified go to this file and so on. Basically we can just see how many here are allow list and you see this is everything in not in the code it is in the commutation which can easily be replaced and well there is no problem in doing this. So we will replace this one and let's go to this action. How many just one occurrence. Here we go. We replaced it whitelist allow list. So we are modifying basically the commutation. Now there are like several more files. Let's go here and here we have this well plugin whitelist. And I'm not sure that we are able to replace this because we'll break some links. Let's go to this one. We have here 85 occurrences. Well let's just see what we have whitelist and there is link. We can open this link and see what is all about. Just a moment. Let me see. It doesn't bring us anything. Okay. But let's go next and see what we have here. Well it looks like most of this is related to the code. Most of this is related to the code and well you can see that it is like the name of the file, Java file here and well if we can start like modifying this right now it is a little bit more complex. Well I would suggest since we are talking about the commutation let's just don't touch the code at this point and stay with the commutation. Let's go back to this to our IDE and well make sure that we already choose these files and what we can do right now we're still in this branch. We're going to well execute this make run command and then we're going to switch back to let's switch back to my reading file. Here it is and we're going to make run and this is my run in this make file and this is how you run your well build your local site ID. So it will create build the entire site and will start Docker container, instantiate Docker container and it will start it on localhost 4242 and you can like if needed change this port but I would not recommend for new contributors to doing this and go inside because this was written make file but really smart people and so they knew what they were doing. So we just can use as it is. So it is executing this pipeline initial Jenkins file in this repository and it will start this. Let's try to open this and see if we'll be able to not yet. So let's go to this it will take some time executing pipeline so it's still trying to do all these things and here we are. So it's like started this let's try to go back and reload and we can see that we have we have this actual our own site localhost and we have it here and so we can for instance let's see you know we change this plugin site doc and I guess plugin site doc it is in developer guide and tutorial tutorial it is somewhere else probably let's go back let's go back let's go back and it is reference documentation maybe plugin site here and let's look for what we didn't find it what about allow list allow list here we go so this is what we changed and we can again just click on this and see that it works and here you have this well it goes to another site address center too and see you can see our white list here and well it gives you some clue of what can be done next so when you start doing some changes and we are stopped doing some requests you will get understanding well this is how I can just continue contributing and it is very easy so well it's what's interesting about this that it is well you will decide it's very kind of interpretive mode so in case if you will change anything here it will modify the site as well and so you will just for instance if you go to id and you want to change the plugin site and you want to change for instance here put something like Jenkins save it go to this site refresh it and you will see Jenkins plugin site and so it is very easy you will see what kind of what it changes what you will get basically and you don't need to restart which is very very variable let's go back and remove this save it again so we'll restore this okay so now you already changed it verified with just simple send it to test them all files well that your changes work and so you can just easily after that go back to your id let's stop this here let's stop this for now we are stopping this docker container which was executing right now and let's go to so we'll not forget reading file and we can just start contributing to this so we will do this git status it will show what are we added so we can just get add content and again do git status for instance so all our four files have been added and we can just do git commit minus m and we can uh oh i put fixed terms uh yeah so we fixed terms in dev section or talk something like this and we'll do this and after that we'll do git push uh oh i already uh all always forget how uh you need to do this correctly it will just remind us and you're trying to push it to your uh to your own uh repository now after that you can open this it will show you what to open and you can uh here uh just uh it's possible to mention that while you some files uh we hadn't touched some files since we'll require um modification of code because while code modification is a little bit different and we can bring a lot of uh links and so let's not do this right now so just mention this create pull request and after that uh well you'll see how uh like everything is automated process kind of except reviewing of course uh uh you will just basically wait and uh see uh what is the problem like how the checks are going what's interesting that some checks haven't completed yet but there is process already going on and your testing start and uh well you know jenki's project is using uh below ocean plugin and just you can go inside and see how everything is uh uh well during the process so basically after that you sit and wait until uh you will receive approval and probably most likely you will receive it in email uh and uh well i just go inside details what you need to do to fix one specific recommendation i hadn't shown that reading the file but i would be glad to do this in case if we would so you well you know how easy it is to do how easy it is like to contribute to the jenki's project in the commutation area i like so in different other areas mark will show how to do transformation from dk page so you're welcome uh please start contributing and well you will have a lot of fun doing this on this optimistic note i would like to end my presentation thank you thank you Vlad thanks very much yeah there is a question in the chat so mark prepares so the reading file you shared is a very helpful step by step guide is it available for everyone or is it something you use just for the presentation uh do you want me to answer alec yeah uh yeah well i prepared it just for my presentation but i would build that to share this and just we can discuss where to put it and i will be glad of course to share this no just yeah it's not private it will not be private thank you there is another question which is further related to jenki's core so from navin i'm getting that jenki's core is quite stable so the most of work happens in the plugins uh so there are two answers firstly indeed the most of work happens in the plugins but it's not just because of the jenki's core stable but it's because of the most of the jenki's functionalities in the plugins jenki's has a framework system and the jenki's core is related to small implementation which implements core foundation and APS for jenki's but all the business logic all features the most of web interfaces etc they happen in the plugins so that's why it's a good error to contribute especially since any plugin is basically a semi-independent project with a smaller code base so that you can actually ramp up and explore them yeah i like i like that observation as one of the one of the genius elements of the jenki's project is it's got lots of small projects where individuals can contribute very effectively with without worrying about disrupting larger organizations or big monstrous things so a wholehearted agreement plugins are a wonderful way for you to contribute and help yeah no we have some plugins which have a size quite comparable to the size of the jenki's core okay jenki's core itself is not quite stable in terms of well it's quite stable operation wise but code wise it keeps evolving with a new apis integrated there is a lot of ongoing work for example for user experience improvements and the jenki's core and its apis so inside this component there is also a lot of work happening at the moment also all kinds of performance optimizations etc so if you want to explore jenki's core it's also possible so yeah this the code base of jenki's core is just it's much bigger and jenki's has a 15 years of history which includes binary compatibility etc so the code is not straightforward in many cases just because we have to retain binary compatibility for the plugins but if you want challenging tasks you can definitely take a look at the jenki's core also there are many areas which are quite isolated which you could try now i like the question from Navin Navin Sundar about any plugins recommended for a new jonna developer and and so i have a shameless self promotion technique contribute tests most of the plugins would benefit from more tests and if you as a new developer would like to learn something about the development experience writing a test inside of an existing plugin is often a very good way to explore oh how does this work and why does it work that way i spend time in the debugger watching my test watching that i assert correctly and that teaches me more about the code embarrassingly than most other activities that that time developing tests is quite helpful so for a new a new java developer help us write tests plus there are many newcomer friendly issues submitted also there is a lot of refactoring available because jenki's we literally use java eat now but yeah a lot of the code was created before so the improvements you could make there or maybe contribute to static analysis of cleanups but yeah writing new features also there is a lot of opportunities to check out the existing tickets there is a lot of small things you could do now we've got we've got a question where are issues that i can work on i think this might be a good excuse to highlight the newcomer friendly issues table in the jenkins in the jenkins page which would be okay if i share briefly all i yeah you're doing the presentation next anyway oh good okay so let me let me do that i think i think i may skip that presentation that i was thinking of but i just like to show this as a way to highlight what um what they can see just a minute let me get the right thing so that i can bring it on screen and this is at least for me it was a good insight of oh look what you can do yeah the places you can contribute yeah here it comes so sharing screen now and you should all see a web page so this is a page that shows the newcomer friendly issues in the jenkins giro bug tracker and you'll see here there are 63 bugs listed for the jenkins core that are newcomer friendly there are 14 listed for the git plug-in 27 for warnings ng now those two plugins that i just mentioned have very high usage in the git environment in the jenkins environment and so if you contribute a fix there you're contributing significantly to help the project so this friendly issues table is is a nice easy way and i'll paste the link to this into the uh into the chat window now the next question was is anyone available to guide a new dev and the answer there is we've got the chat channels that will happily help new developers we've got the jenkins dev mailing list as well both are willing and ready to assist now i'll send the links to the chat thank you now i'm hesitant to go beyond the hour that we had originally allocated oleg do you think it's okay for me to spend time doing a plugin migration or should we call this a pause stop the recording and switch to q&a oh i thought it's one hour 30 great so so let's go ahead at least this is what is in jenkins calendar perfect then then i'm going to go ahead and show show how i do i do a plugin migration so one of the challenges we have is that our jenkins documentation had spent the longest time in the jenkins wiki and that's a great place to edit except that we had some spam challenges so about a year ago we started a project to transition from hosting the documentation on the wiki to hosting it in github this page that you see here highlights our progress and i'm i'm very pleased to show that we've we've completed over 500 plugin migrations in the last year plus that's really great but we've still got over a thousand left to do so there's lots of work to do to get the plugin documentation migrated into github so that maintainers can maintain it more easily so that you can we can update it so that we can deliver it with new releases so how do we do that well first challenge is let's find a plugin that hasn't been migrated yet you'll see here on the status column and if i just i'm i'm kind of lazy i'll just page down and find a row that has there's one that i thought i'd like to try this one so here is the x unit plugin it's used it's installed in over 19 000 installations i thought i'd like to migrate that so i open up the jankins wiki exporter jankins wiki exporter dot jankins.io and paste into it the url to that plugin now that plugins wiki documentation looks like this it's actually quite good it's got pictures in it it's got a good good content list different insights multiple levels of content it's a very good piece of documentation on the wiki but it can't be edited because the wiki is now read only so this export process when i click that convert button it will generate it will read the wiki page generate a zip file from the wiki page that includes the pictures as well now i didn't want to wait for this for purposes of our demonstration so oh and there it is so when i open the zip file you're going to see it's got the read me and it's got the docs images that are my pictures so there it is helping me along the way now what i did then was i copied that up to my development location and let's make the text here bigger there we go so this is the x-unit plugin that i had forked and i'm on the master branch right now so i want to check out my new branch migrate docs to github and as it turns out i placed the zip file in my home directory there and i'm just going to unzip it in this so what that is unpacked the things that the converter did for me and placed them right here i've got docs images i've got the read me file and if we look at the read me file we'll see that it is marked out now there's there's lots to improve there but you know what in this particular case i can just say get add everything and now if i get commit i have something already that i can push to github and go look to see how does this look when i present it on github so migrate documentation to github and probably help if i say from wiki to github so that easy and i'm going to push that so just push and now it's ready for me to go to that branch and i'm not actually ready to submit a poll request yet but i would like to see how it looks so let's go look and see how it looks so we're going to ignore that and just jump right to my fork of this plugin where we'll find my branch migrate docs to github and if we look at the read me file now you'll see here is the translated documentation that a read me didn't exist for this repository previously and now here's this read me that has hyperlinks in it it's got the pictures it's got content and it all looks actually pretty good okay i me personally i'd want to get rid of some of the empty space here i'd likely make a make an initial heading so there are lots of things that i might do to further improve this but this is already a pretty good first effort and that pretty good first effort has transformed the documentation from read only on a wiki page to being able to read right inside the github repository that the maintainers will be able to care for so we've we've made a main to maintainability improvement if we submit this poll request just as it is so it's it's that simple and i'm going to go ahead and risk annoying the authors of this plug-in i'm going to start the poll request i'm going to actually make it as a as a a draft poll request so they know that i'm still working on it because i think there are some things i want to improve and so i need to mark this as a draft i'll create the poll request and let's see oh like help me remind me where do i mark this as a draft there is a technique there uh do you really need it if you want to get the reviews because draft marks the poll request is not ready for review and at this point i'm actually not ready to have them review it because i'd like to make a few corrections before they then uh yeah on the right side there is reviewers on the top still in progress oh there it is convert to draft thank you yes so thank you very much it's convert to draft and i'm going to temporarily convert to a draft so that i have the time to work on this before the reviewers get involved but that that's the the basic concept and this way you've seen how to do those kind of simple transformation so i started from what needs to be done this page that this what's available is work i exported the existing content i did a little bit of terminal work here to to package that and submit it as a poll request and then back and i'm ready to ready to work on the poll request further improve it make it better get it ready so that the the reviewers will have access to something that i'm ready for them to review that covered the part that i wanted to talk to and i think i can stop sharing now we've got a question in the q and a about hey can i start working on document migration absolutely documentation migration is a is a topic that we need we've got lots of issues in our in our jankins.io site in github issues that are specifically documentation migration tasks now what we've found is that the wiki as it's evolved over the 15 years or the 10 years it's been maintained is not always current so it's not a not always a simple trivial conversion from one format to another it requires thought and consideration evaluation and improvement as you're doing a migration of content from the wiki to jankins.io olake olake smiles i like that that's good there there are some stories behind those kinds of transitions that there are times they get complicated or where we need to have longer conversations about those details but in many cases it's quite straightforward and it's generally being official for the project it's not just moving from one source to another for plugin documentation etc moving the documentation to github allows us to follow the documentation approach one features changes get documented along with changes themselves which helps us to maintain actual and version documentation plus we can also automate release flows and now if you go to documentation of existing plugins you can see that documentation updates also referenced in the change logs so they become more traceable for users and of course it's also good from the recognition perspective but yeah documentation yeah main purpose of that you know it's a really collaborative format it's a support for reviews we support for versioning and it really helps everyone in the project documentationist code really has been a very a very nice positive the things that i've interacted with i found that the documentation is significantly better now for plugins that have made that transition from wiki-based documentation into github they are more likely to update it more likely to care for it and maintain it and be willing to accept and consider pull requests the correct mistakes in it and that covers that covers all the topic that i had i think we've got a few concluding concluding slides if there are more questions we're happy to have questions so if there is no question it's again we will stop recording soon and after the recording we will grant everyone who stays online voice permissions so you can ask more questions great i'm going to go ahead and stop the recording now oh that's you yeah i was just looking for closing slides you were referring to excellent oh this one that that's that's the one absolutely okay this one too yeah so if you have any questions please contact us in this github channel jnkca slash october 1st we will be happy to answer questions providing guidance how to resolve issues debate something you need it and thanks a lot for your interest in meeting to the jinkins project and we are looking forward to meet you in the community channels so have fun thanks all right thanks lad and thanks to jonathan