 Down three, two, one. Welcome to the European Jenkins Docs Office Hours. This is the September 8th edition. Today, we have a few topics regarding things like the LTS release that we just had go out yesterday, Google Summer of Code, and a few other things that are coming up, such as DevOps World and Hectober Fest. So first things first, action items. I'll go about my DigitalOcean blog post. There's one coming, and I'll be writing it soon enough about the sponsorship that we're getting from DigitalOcean right now. And Mark, did you have any updates on the other blog posts and items? No progress, unfortunately. And some of them I may drop off the list and just get lazy enough. All right, fair enough, no worries. Great, all right. Vihac, would you like to share any updates in progress that you've been able to generate since last time? So Google Summer of Code coding phase has ended, as of now, the time is concerned. So after last week, the issues that we are facing and the changes that Chypni proposed, those issues are resolved, and the request is finally merged, and we can see those changes on Jenkins.io. Then we were investigating a bit on build steps from JSON, ASCII.Doc, which was the only ASCII.Doc in which we faced some issues correcting. And the reason behind that was the HTML for it was not correct. And there was an extra LI tags, which were not nested within the UL tags, and some extra nestings which were not done properly. And because of that, the page is not rendering correctly. So as of now, I was able to get it manually and get some results done, but getting that done automatically does not seem to be feasible in the short run. So the change that we are proposing is to simply say that this could take any step, and maybe then we can say that try out the snippet generator, for instance, if you want more information on this. So we can create a manual ASCII.Doc that will replace the one which has the incorrect intent on the page right now. So that is something that would not fall into JSON, but something that I would want to do to get that pages on it. So yeah. So VHUN is that one where we really ought to fix the plugins HTML file, the plugin documentation itself is the problem seems like it's really in the plugin HTML, not in the tool. Yes, sure. The help or HTML that is associated with the plugin in that the help that is listed in the LIG tags does not have any surrounding UL or event tags. So the problem and because of that, the main website which has the other listings also, it's getting confused and the indentation is going all over the place of the lists. Yeah, so that seems like a, okay, maybe in a perfect world, the tool would somehow adapt to flawed HTML, but really that HTML is not going to render correctly anyway, right? That's now relying on a browser that will accept an LI tag outside of the list that defines that there should be an LI tag. Right, right. So are you interested in submitting a, oh, go ahead. Go ahead. Are you interested in submitting a pull request to the problem plugin? If not, that's okay. You can just, no, not really. And Bruno or I or Kevin will take it on and we'll find a way to submit it. Okay, like if you can create a pull request on that and then maybe you can tag me for any additional details required for my site because I'm not really sure about that particular plugin, but yeah, I would love to help in any ways possible. Okay. For my site. But for the shorter, so that the website works properly and somebody who goes on that page does not sit waiting for 30 seconds for the page to crash finally. We could give an alternate content that says that, okay, this can take any step and refer to the step I generated for what it is. Something that should be understood as the solution to that problem on the channel. Great. All right. Mark, did you have any other questions or pipe pieces you want to share on this one or would you like to move on to the other improvements in doc storing? I think that covered it. So I was a little distracted because it was about to prepare the pull request. Fair enough. Okay, great. So then Mark this other, this note here about the backend extension indexer being updated from you and Basil. Yeah. So Kevin, let's first give everybody an overview. What's the backend extension indexer and why do we use it? So could you open up Jenkins.io? Of course. And in the search box at the top right, look for the word extensions and pick any one of those items. Right. So Jenkins has a concept of extension points. What this is is it allows one thing to declare I'm creating something that other people could extend. And the other people then are given a place, a technique that they can use to extend that thing to implement an extension of it. So for instance, if we, instead of, if you're willing to edit your URL up at the top instead of the word J unit, change it to the word get. Okay. So now we're getting one that's familiar to me. All right. What's happened here is the get plugin has implemented an extension point called build chooser. And the build chooser then has been implemented in four plugins in total, the alternative build chooser, the flaky test handler, the Garrett trigger and in the get plugin. They each allow a separate plugin to add capability to the get plugin. So it's kind of a cool facility, right? It's a really, a really elegant sort of thing to say, oh, somebody else who isn't the get plugin can add capability to it. And, but we need to be able to document these things. And so we have this tool called the back end extension indexer that looks at the whole suite of plugins and reads all the extensions and all their implementations and then generates these pages. So Vihon will probably recognize this pattern because this is exactly the kind of pattern that the pipeline steps doc generator uses, right? Where it reads all the plugins, massages them, runs them through a series of transformations and presents pages. Well, the back end extension indexer had been un-maintained for quite a while. And I started a pull request that attempted to modernize it to Java 11, but I couldn't do enough to get it all the way to done. And I just stopped because other things had to take priority. Thankfully, Basel Crow has detected that work and said, hey, he's gonna take it the next step. And so he's doing the awesome work that Basel does of taking this thing and seeing, hey, can we fix it? So that's the work that's happening right now in this back end extension indexer. It used to be, and again, Vihon will recognize this pattern, it was built with Java 8 or in back end extension indexer, Java 7 or maybe Java 6, it was that old. And it's now been updated that the SpotBug's warnings are generally resolved. If not, they're at least suppressed. It compiles with Java 11. It has been modernized to use a current Jenkins parent POM, et cetera. So all those things are in progress. Wow. Any questions? I'm happy to answer questions, but right now the work is still in progress. But that's already impressive. Well, it's nice because it's great that Basel picked it up because my estimate was I wouldn't be able to look at it again until at least November. And Basel saw my comments and said, November really is not terribly satisfying. Let's try to do it sooner than that. Well, big thank you to Basel for taking this on and working on this. And that sounds like it's gonna be an amazing set of updates. And once it is all modernized and ready to go, it counts. Yeah, no, it actually won't alter anything in the UI, right? The UI should remain the same. And we haven't had the same level of complaints about this UI because it's intensely focused on developers, right? This is not really useful to someone who's using Jenkins Pipeline. This is a developer centered page. Okay, but for the time being, it's still working despite being running with Java 8. Okay, so nothing is broken, but you're doing something great, don't you? Exactly, and Bruno, you said it exactly right. It is that the current tool works, it's just badly outdated. And what Basel's work is doing is modernizing it and assuring that it still works. Cool. Very nice. Okay. Great. Anything else on that one, Mark, or is that pretty much? That's it for me, thank you. Okay, yeah, of course. So next on our agenda is the Jenkins September LTS, 2.361.1 was released yesterday. Pretty much successful release. There was one issue that was reported regarding the web socket, but with it not being as widespread as it could potentially be, we're looking into the case by case of what's going on there. The change log and upgrade guide have been published and there was also a blog post that was requested from the Continuous Delivery Foundation for their blog. That's available here in the agenda and has been pushed out there. They've also tweeted and posted on LinkedIn about it. So the release is going well. Thank you to everyone who helped and participated and just did anything to make this a success. Special shout out to Chris Stern for taking on the role of release lead for the 2.361.1 release. And today, actually after this is going to be a live stream with Mark and Derek Hope which will be available on YouTube that will go over the 2.361.1 release features, changes, highlights, et cetera, et cetera. It'll also be available after the fact that it's going to be recorded clearly. So yeah, Mark, do you have any other items or topics that you want to mention that are in regards to the live stream? No, that's it. Well, Derek and I will be talking about it and it'll be the usual Derek and Mark talking. Okay, great, best show ever. Next up on the list, we do have the next LTS coming up 2.361.2. The release lead request has conversation has been started and developer mailing list. Chris Stern is actually interested again and has shared that interest. Right now, the plan release date is October 5th. So once we get the ball rolling on that, the backcourting change log upgrade guide, everything will start being compiled. Next up on our agenda, just quick talk about DevOps World 2022 which is September 27th to the 29th. This is big. This is back in person, which is really exciting. And we have a bunch of great talks and subjects that will be displayed and shared with the entire community there. Mark, did you wanna mention the pull requests and modernizing plugin progress? Yeah, so this one, Bruno, John Mark and I are doing a workshop at DevOps World. The workshop is how to adopt a plugin or how to modernize a plugin and prepare to adopt it. And what we're going to do is take participants in our workshop live through the experience of submitting useful and valuable pull requests to the Jenkins plugin of their choice. We've adopted, Bruno, John Mark and I have adopted, it's actually over 25 plugins and are preparing those steps, the improvements in an answer book. We'll then ask the students, hey, please go ahead and implement this. If they get terribly frustrated or if they are unable to do it, all they do is they open up the answer book and see, oh, this is how they did it. So the big win for us with this is that we will get these 25 plugins, 25 plus plugins, we'll have modernization pull requests ready, whether they're from the students or from John Mark, Bruno and me. And at the end of this exercise, we intend to apply all those changes, whether it's from us or from one of the participants. And we look forward to using the same technique in Hacktoberfest. We won't actually do live workshops in Hacktoberfest, but people will be able to use the tutorial that results from this to do those same kind of steps. Two birds into one stone. Exactly, several birds, one very small stone. Fantastic, and yeah, that just sounds really great. And I'm excited to see what the results are and how everything goes with that. I'm already taking a look at the modernization myself so I can already tell just how involved it can be, but it's nice that we're making it a little simpler for folks. And yeah, I'm currently working on the dynamic search view plugin as part of that. So going through updating the parent POM, making sure that the jelly files present, et cetera, et cetera, et cetera. So I'm learning a bunch and it's really exciting, yeah. Yes, and you're a nice guinea pig for this tutorial in the state it is now. Thank you, Kevin. Yep, exactly. I got a great perspective right now, so. And we would love to have more people do exactly that same thing. The more reviewers we get of those steps, the more likely we're, and after we merge it, we'll still take changes, right? This tutorial is not dead when we've finished it. We'll keep enhancing it. Right, and things change constantly. Any updates or innovations that come along could change things. We have to be flexible with it, so. Great, all right. And speaking of Hacktoberfest, Mark, do you want to share some more insight on Hacktoberfest itself? Yeah, just today, the hacktoberfest.com website went live. And so we've got confirmation that DigitalOcean is running Hacktoberfest. It looks like it will be a slightly different process for contributors. The attractive part of it, go back to that page, Kevin. That was perfect. There's a very attractive piece. It looks like they'll start taking registration September 26th. So just as we're launching DevOps World, they'll start taking registration so we can actively promote it at DevOps World, say, hey, register here. If you scroll a little bit further down, the thing that I find most attractive about this is they've got a proposal here that attempts to allow non-code contributions to be considered in... Oh, wait, let's see. It must be up above, Kevin. Sorry, I know I had seen it. Oh, yes, new for 2022. Go down about halfway. Keep going down. Down a little further, right there. Whoa. See on that right-hand side? Non-code contributions. And this gives us a chance for them, for non-code contributors, to also be recognized. Now, thankfully, Jenkins documentation is all as code, so it's easy to recognize that. But one of the gaps we had in years past was it was very difficult to recognize contributions from translators who were submitting their contribution through crowd-in. We've got a very nice translation front-end over the top of some of our plugins. That nice translation front-end, however, does not credit the pull request to the individual who did it. So this facility may give us a way to allow translators to also get credit for translations they submit through crowd-in. Now, I don't know how it's gonna work yet, so this is me speculating and hoping. But anyway, it's written advocacy with two stars, but talks of presentation, technical blog posts, podcasts, KSTD, social media, blog posts. Whoa. Oh, everybody can contribute. That's fantastic. Well, and notice on the writing line, translating is over there on the non-code side. And that is a very real, translations into your native language is a valuable contribution that many times is not done by pull request. Yes, and I made a proposal a few weeks or months ago saying, hey, shouldn't we add something with crowd-in to which we answered, no, we can because the original poster won't be credited. But now there may be a way to credit the people who will do some translation and that's great. Exactly. So what this further lobbies that we may have benefit by putting extra energy or having others put extra energy into internationalizing and localizing. And they're both valuable activities. Internationalization typically is done with pull requests. Localization commonly is done through crowd-in or we hope it will be more and more done through crowd-in. Yeah, so thanks, Kevin. That's the current story on Hacktoberfest. At a minimum, we have a good path for documentation contributions there. If we go back to the notes, there are more things that we should talk about here today if we've got time. Yeah. So stay on that section right there because in the Asia office hours last week, we took on that next bullet item, a list of approachable documentation tasks. And what we realized is that there are some things that are good for Hacktoberfest and there's some things that are really, really bad for it that are not a good fit. So on the good side, that good first issues query identify several Jenkins.io issues that a brand new user, a brand new person with no Jenkins experience could successfully help with this. So these things are intended to be for complete novices. Now, if you go back, there are also places where, but what if I've got some Jenkins experience? Okay, these labeled with Hacktoberfest are intended to be you've got some experience but you'd still like to contribute. So we've got two layers there. Now, if you go back to the page, there's yet another challenge, which is we need to review the existing open issues. Yeah, that's the right one to open Kevin exactly because there are 146 open issues and only a tiny fraction, like roughly the first 30 have actually been checked to see which ones are good first issues, which ones should be assigned to Hacktoberfest there. They need some skill. So we've got work to do there and office hours is a good place to do that work. So that's one where we may want to consider if time allows today that we spend some time looking at those and doing some assignment of labels to those things, back to the other page, Kevin. Okay, so those are two, those are contributions people can make to Jenkins documentation. The next bullet item, plugin documentation migration to GitHub is a little more challenging because it is dependent on plugin maintainers to do the reviews. We can do the reviews of jankens.io docs, right? Kevin, Mark, others, right? That's under our control. Documentation for specific plugins goes to the individual plugin repository and therefore the reviewer for it is the plugin maintainer. And if they are no longer active, a pull request might sit and never get attention. So if you'll click to open that migration report, we can see get a hint of what this thing's like. So what this is, is this is a report that tells us which plugins have completed their migration to host their documentation in GitHub. And it's a good number at the top. At the very top, we see that there are over 900 plugins that have done it. But unfortunately, there are still over 900 that need to do it. So there's a lot to be done. Now, if you scroll downwards, Kevin, or actually order by, we can use the ordering of the page. Go up to the very top and order by status. Here we see plugins that are needed, need it done. And there are a lot. So for instance, if we look on this page alone, the Allure Jenkins plugin has 16,000 installations, but still needs its documentation converted. That's probably big enough to be interesting or even further down Ansible. You can see that one. Ansible has 21,000 installations and still is to do. Now Ansible is a little awkward because if you click it, you'll see, now if you go over on the right-hand side to GitHub and click the open poll requests, so tops, top left, yeah. You'll see move docs to GitHub. Mark waits poll requests from a year ago that hasn't been merged. This is exactly the problem that this kind of poll request to a plugin can generate. Because no one's reviewing it and therefore a Hacktoberfest contributor won't get credit for it because it wasn't reviewed. Is it an abandoned plugin or not? It's obviously not being reviewed by whoever the maintainer is. I don't know if I would call it abandoned, but it's certainly not that this poll request that I think is a trivial poll request has not been reviewed. So I guess what I've highlighted is plugin migration, plugin documentation migration is a good Hacktoberfest topic. However, it would be best if we could find a way to flag those plugins, which we know have active maintainers. And that's a more challenging topic because it means we have to ask the maintainers. Are you active? Will you commit to review a documentation poll request to your plugin? And many of them either won't respond to the request or may say yes and then not do it. Any questions on this plugin documentation migration? Not in it? So now there is, I guess there's one bright spot in this. The earlier thing we talked about for DevOps world means that Bruno, Mark, and John Mark have adopted 25 plugins. Of those 25 plugins, we promised to review documentation poll requests. So we've got at least a list of up to 25 that we know someone will review those. Yes, we promise. Exactly. Well done. Well done, Bruno. So we've talked about two, I've talked about two good things for Hacktoberfest. Let's talk about a bad one. Tasks intentionally not recommended for Hacktoberfest. And this is one where we've tried this one in the past and we've done it two or three years now. And you can see the results of our attempts and that's why I'm explicitly saying we don't make this same mistake again this year. Click that wiki migration poll requests. What these are is these are poll requests in Jenkins.io that are flagged with the wiki migration label. And this is for Jenkins user documentation, not plugin documentation. So if you look at the topics here, it's things like, how do you diagnose build failures? How do you use parameters? How do you write a unit test? How do you do internationalization? Those are all things that are not really specific to a plugin. They're general purpose topics. And what people have done here is they have done exactly what we asked them to do. They took the wiki page, converted it into ASCII doc format and submitted as a poll request. The problem is inevitably the wiki pages were out of date. And these people didn't know which things were wrong and which were right. And of course they didn't. They were new contributors. So they submitted these transformations, but the transformations can't be merged because of the inaccuracies that are in them. And what does it take to fix the inaccuracies? It takes an expert Jenkins user or an expert Jenkins administrator, which means we didn't help a whole lot by submitting these poll requests, right? Because all we did is pile up a bunch of work for experts who already have more than enough work. Gotcha. Okay, so this one, back to the Google doc, that's why I would strongly recommend we not invite people to do wiki migration this time. We rather recommend them away from wiki migration because it just doesn't, and it doesn't reach all the way to the user because it cues something up for experts to then review. And it's not even just review. It's really review and correct, right? If it were just review, that's a different thing, but inevitably pages that were written seven or 10 years ago are now incorrect. They're not just old, they're incorrect. Right. And that's it for me. So any questions on any of those topics? And we'll continue to determine all these open issues and everything here, Mark, and the docs, office hours, and so forth as well. Unfortunately, we've run out of time today, but maybe next week we'll have time to actually do some issue processing. Yeah, I think so. And yeah, we'll make a point of it. So take a look. Yeah, so as Mark mentioned, we're up against time. So just really quickly, Gavin proposed a commercial support page update. It is available, the link is here. We haven't had a discussion on it in the last few weeks. So if there's any feedback or ideas or just general ideas that you might want to share on that, please by all means contribute, feel free to click on the link engage and share that because it's definitely a working progress. So yeah, outside of that, are there any other items or topics that anyone wanted to mention or is that cover everything for today? That's all my topics. Okay. Okay, then Mark, I think you'll be able to stop sharing the video or stop recording the video. This will be a.