 This is documentation office hours. It's the 9th of September. It's Asia time and we've got two of us attending here. Let's so agenda items action items, Google summer of code. Other tooling and this is one will show a demonstration of this other tooling. Then Jenkins to 361.1 released. 361.2 upcoming in October. DevOps world. October fast. And that's it. Any other topics you want to add Meg. Nope, that should keep us busy for a while. Okay, so action items I've made no progress on the archiving or on the blog posts it'll just have to wait. The DevOps world is coming and I'm full on focus there that'll, it'll be at least October or more likely November before I get there. Before I get to those action items. Google summer of code though this one's fun, because in a, we saw from the Han for the demonstration of the pipeline steps reference, and it's coding is done. It's final it's deployed and it looks and loads really quite well. So when I search for checkout. Oh, it's fine. And it loads lightning quick. And that's because the file is dramatically smaller because beyond has separated things like this page into its own dedicated page. Did you come up with the idea for this or was this something out that somebody else had known and he just implemented it. This is something that he actually proposed and reviewed with Kristen Whetstone. And, and so they, they came up with it together beyond implemented it. And he's, he's the one who structured, who made some nice structural changes in addition. But I believe the concept of this partitioning and split came with a combination of him and Kristen working together. Yeah, very, very nice. So now in addition to that. Now there is still there's one page that's needing some work, and I've got the action item to see if we can fix the plugin source code that's causing the problem. But it's, it's only one page. It's something about Jason. And I don't know that I need to show anything about it. It's, there's a jab build steps from Jason plug in this thing when I click it. No, there. Yes, there it is notice this thing in the top right hand corner. Yes, that hints that something went badly wrong and notice that it's still loading the page. And the page is quite, quite huge. But V Han indicated what's wrong is there is some miss formatted HTML inside the page and the scanner thing can't handle that, that badly formatted HTML. So, but we may be able to just fix the plug in that's contributing it. Right. And, and if not, I mean, you're not left with total garbage for the page. Well, and, and every other page loads very, very fast and is very workable. So having one page that's not optimal. Whereas before what we had was many, many pages that were that size, right. So, so very, very, very, very nice enhancement beyond has done wonderful things. Exactly. So now to go to go one step further. We have this other concept on the site called extensions extensions are a Jenkins developer concept accessible through this extensions index. An extension point is a way for a component in Jenkins to declare other people can connect to this and extend me. So, this tool the extensions generator has existed for years, and has been generating this page well this page previously had 80 entries in it. Now, thanks to fixes from Basel Crow, it has 100 plus. So there were many things that were just simply missing and really glaring kind of things like the get client plug in is no longer missing. And the get plugging is no longer missing. So the, the, the other benefit of the work that Basel did is it also now has instead of previously the one over 1000 error message that is the tool was generating while it ran. It's down to only 167 and those 167 are for are for truly ancient plugins. So we've got much more content, much better content, and special thanks to Basel for his work on it so the here are the ones provided by Jenkins core. It's really an amazing piece of work. Oh, that's lovely. Yes. Are you going to be able to cover that in your class at DevOps world. It won't actually need to because of this, this piece is not something that plug in maintainers or plug in new plug in maintainers even need to know. Okay, this concept that they won't even have to have to handle yet. Okay, cool. New page has I think it's over 120 extension points. So, big win there. Yeah, next next topic is two 361.1 has released. It released on Wednesday. It was successful. And there was a live stream that Darren Pope and I did today the recording is available here. And it, it was an hour of us talking about this particular release. I have to watch it guessing a better than you two talking for an hour. We had fun. So we've got an upcoming a new release 2.361.2. Hello, Dearsh welcome thanks for joining. Hey Dearsh. Hi everyone. Thank you. All right, so the release lead, we've got Chris Stern who had joined us last week for for docs office hours, who has expressed his willingness to be released lead again. Thanks to Chris and we'll have a release coming out early in October. We'll get to the big ones. So these big ones make you remember that we've been going through this modernizing a plug in, and actually dear as you've been involved in this as well the modernizing a plug in tutorial. And what we see is here's the let's see let's get the yeah here's the things that we've got so far. 1015 20 of them that we're preparing to show have merged in time for DevOps world at the end of September. And that mean we'll mean they're also ready for people who are new hacktoberfest contributors to use these tutorial steps to contribute to Jenkins in relevant and substantial ways with detailed steps that they can follow. Wow, fabulous. Awesome. Yeah, so it's it this one we've got several of us working through it. And, and the process is feeling more and more smooth all the time and it's a place where the documentation generation process we're using actually makes it quite elegant because most of the many chunks of this thing are boilerplate that are automatically inserted. So things like the branch name things like this commit message, things like this file that's being added are all part of standard boilerplate so that we make a change to one place and all the pages get the update. Oh, yeah. So, we've got 25 plugins that we've adopted as part of this tutorial, and we're going to modernize them start the step so that when the students come to the workshop in DevOps world. We'll have the answers ready for them in case they can't solve the problem themselves. Oh, excellent. Yeah, so that covered. Go ahead. What was that. Are all the steps completed on the Jenkins website or some of them are remaining. Oh, there are many steps till still to be done. So for example, what we've got right now is several of us are going through these doing taking them on a test drive. So I've been through the added Jenkins file update parent palm convert translations, move the description and update Jenkins version so I've been through the first five or six one more time. And, and they, they have passed my most recent test, but the other, you see there the other 10 or 15 still need to be run through. And the content that is supposed to be there is already in that contributing to open source document right. It is right so the original, the original document the source document gave at least some rough outlines of how to do that. Okay. Sure. So is there any volunteer yet that you know who is willing to work on this or are you only working on this by yourself. Oh, we've got several volunteers so Kevin Martins has taken on being a documentation person who test drives the instructions without being a Java programmer and Bruno Verrachton and john mark Mason are both also reviewing it from the perspective of programmers. That's nice. Yeah, so so we feel, I feel like we're on track to, to have something ready to publish by the time DevOps world reaches on the 26th or 25th of September. Okay, that's what I was expecting to like trying to know. So that's nice. Great. Yeah, so, and, and it feels right now it's it's feeling pretty good. There's certainly lots of work to do because you can imagine with 25 plugins. Every one of them needing some modernization steps. We're spending lots of time figuring out what those steps are and making sure they work. That means that it takes work to do that. So let's see let's take an example here. Here's the MS build plugin. And we see it source code here. The poll request is fixed now if we look at the, let's see if I've got no I don't have any submitted here so let's use instead one that I know I've done a submission for like badge. So here is the, the canned answer ready for the students in this repository. But when they work with it they'll work with this repository and attempt the work themselves. So they try it and if if they're unable to solve it we just change their URL slightly and tell them hey look here you can find the answer. Oops. I just spelled correctly docs with their thing with all this technology they could figure out what she meant. No no no that would be just to yeah there we go. So, so it's like the steps, the students are supposed to do for a plugin has already been done on a separate repository for that same plugin. Correct. Yes, you understood it exactly. And you, you only perform those steps. I mean you only perform just one step right the updating the minimum Jenkins version, or have you done for all the other steps as well. So we'll put we hope to perform several steps. I don't think we're going to have enough time to perform all the steps, but we hope to with 25 with 25 plus repositories. So over the course of the next three weeks, perform at least one or two of the steps on every one of them. And of course, the plugins are each at a different state in their modernization. One of them needed a Jenkins file. Okay, but before it could get a Jenkins file, it had to be able to compile with Java 11, which was a whole bunch of additional steps to be sure that it. So, so the first pull request of that one adds a Jenkins file and fixes the compilation on Java 11. Okay. And are you doing this manually or automatically or some code. It's it's done with human human work so manually. There's a there's a tool called open rewrite that, once we understand this well enough, we may be able to express the techniques using open rewrite, but we haven't we haven't attempted that yet and we won't for this exercise. Okay. Thanks. Any other. Any, go ahead. No, I'm, well, I'm, I'm reading docs on the side while you guys are discussing that. Well, I think we're ready to switch then to let's talk about Hacktoberfest. Is that okay. All right, so Hacktoberfest is coming October one through October 31. And the site has just been opened up. Hacktoberfest.com they show 17 days to launch. And it's new this year and that you will, you will register on their site to be part of Hacktoberfest. And they've got now this one should bring joy to us. They've got a way for non code contributions to be contributed towards Hacktoberfest. Oh, this is this is brand new for this year it's never been done before. I'm not sure yet how well it's going to work. It's, it's still, we got to see what what their rules are etc, but very interesting concept so this allows things like people who do translations from one language to another even if they don't do it through submitted pull request can get credit for those translations. That's nice. So the challenge for us though is is this is the bigger picture challenge for the documentation team is, we need to find a set of issues that are easily approachable. Well, let me let me put a higher level first. What I think I've found is there are two key areas where we can do something with Hacktoberfest and do it well but there is one where we've tried it in the past and it just didn't work and so I'm this year I think we intentionally avoided so two yeses and one no. So the idea on the yeses are Jenkins.io. Those are those are good yeses we can, we can have people we can identify issues on www Jenkins.io and create good first issues or label them so that people can come in and help us with that site and submitting documentation to the site is is not that difficult so they can do that. Yes. In addition to that with where we want to label things Hacktoberfest that need some experience, but are still approachable for people with experience. So that means we've got to do reviews because right now if we look at these lists good first issues is tiny. It's got five items. And Hacktoberfest is tiny. It's only got four items where we've got 146 issues that are candidates so we need to do a review and the proposal here for today was in this session let's review these and let's talk about which ones we think are good first issues and which ones we think are approachable for a new contributor if they've got Jenkins experience. So, step one next piece and this is the second. Yes, we think we should do it, but it's got some extra complications. The first one Jenkins.io. We're the reviewers. So we absolutely can can control how well and how frequently review the pull requests. So everyone plug in documentation migration so remember that plug in word means that we can't control because it's migration to the plug in repositories. Therefore it needs the plug in maintainer. So this page shows us. There are over 900 plugins that still need documentation migrated plenty of work to be done. If we look at the plugins to be migrated. And let's sort by status. You'll see that most of them. The source not stable unfortunately okay so I can't, we'll just have to scroll. So that one is a large larger number for the allure Jenkins plug in the answer will plug in is larger. So all of them you see are in the less than 10,000 installations category. And so they may have no person maintaining them actively right now. And without a maintainer, it's, it could be very frustrating to a hacktoberfest contributor to submit a pull request that never is reviewed and therefore won't be counted as a hacktoberfest contribution. So the challenge with this particular task of plug in documentation migration is, we need to find plugins where the authors are willing to review the pull requests. Now we've got a set. Go ahead. Yes. On the similar lines mark you created a excel sheet where you took permissions from those maintenance or ready to look at those PRs. So what do you think about that? Sorry, so you were talking about a spreadsheet. Can you ask your question again. Sure, sorry for that. So you made an excel sheet last time, where you took permissions from the plugin maintainers if they're ready to review the PRs from new contributors. So what do you think about that. We may need to do that. The problem is that was very time consuming. And, and the response rate was dismayingly low. So I sent out requests to, I think 30 or 40 plugin maintainers and I believe I received responses from 10 or 15 and actual action on pull requests from maybe half that. So part of that for me is, yes, we can do this one. But I think our first choice would be to put them on. First choice plugins that mark, john mark, and Bruno have adopted. Right, because those are plugins we know, we know the reviews will happen. And then second choice. And ask, ask maintainers. So, as an example, here's a, here's a second choice is not a good one. It really it at least it wasn't last year, it didn't work as well as I'd hoped. So here's an example here's the Ansible plugin with 21,000 installations. And the work is listed as to do but when we click Ansible here and go to GitHub, we read a poll request. A year ago to move the documentation to GitHub, but no maintainer and therefore, a comment from somebody who's not a maintainer saying hey, yes. This looks good. And a request to the maintainer but no, no, no motion on fixing it. Yes, so this would be not a good experience for have the best contributors. Okay, you understood precisely. It's, it's frustrating for them. Hey, I wrote something I did something a year ago it's still not been merged, and no feedback on it to tell me why it's not been merged. Okay. Thank you. Good. All right. So now now on to the sort of the bad news side. These are tasks that we had tried to do in past October Fest events, and we actually had had people take on the tasks, and some of them have have finally been merged however. It's turned out to be much more difficult so what we have is a notion of general documentation migration to GitHub. These are pages that are typically on the wiki, and they're describing some capability of Jenkins, either a topic of this, this theme agents or that theme system administration or security or permissions or some something something like that, managing a server better. And the challenge is, when they copy it from the wiki and transform it, they aren't expert enough to clean up the mistakes that are in the wiki. And many of these wiki wiki documents are five or 10 years old, and therefore they they do have mistakes. And so what's that what that's left us with is a large backlog of 10 of these wiki migration pull requests that are open, but they need experts to review them and make the corrections before we merge them. And we've just not seen the traction from the experts. Well, you can see we've got some back as old as 2019 that are still not merged. The next question here is let's not ask anybody for Hacktoberfest to do general documentation migration. Let's focus ourselves on Jenkins.io. So then if the two of you are willing. And so Megan did you have something you wanted to say there. Nope. I just created two new issues though. Oh good. Very good. And are they good first issues. It definitely is and the second one I think is, yeah, it's probably. It's a good one first and a half. Okay, five year old off the street to take on but right or we take it in. So malformed x ref. Oh, right there. Uh huh. Good. Okay. Yeah, very good. All right, so this one is absolutely a good first issue. Good victory. And then review and rewrite the intro. Okay, so. Okay, good. All right. I was just, I was glancing and listening to you so not reading but I that that the it looks like it's, it's still the pros from when we were all drinking the Kool-Aid the blue ocean was the future of Jenkins. And we put the disclaimer in. And most of it kind of stands up. But I know there's a section of what is it what happens to classic UI and we said, well, it's not. We still love it. It's not going to be buried in the backyard but you know. So it would be it would be a writing task a pure writing task. Right, right. Very good. Yes, that's well and the new status is in the is already in the disclaimer here. Right. The goal is make it can make the rest of the document consistent with the disclaimer. Right. Good. I like that. Very good. Okay, so are you are you okay last time we met together we did this the same exercise. I'm just going to bring up my screen and let's look at these things and talk about them one at a time is that okay. Yep. Okay, so we have done screen one before let's take, go ahead and do Raj. Yes, I have one topic that I want, like, want to discuss if there's any time later. So let's take, let's take your topic now then because October fest, at least for me I want to have it use all the time that we're going to run out the clock on it so let's do yours. So what's your topic, do Raj. So it's about the topic you and basil were discussing about back end extension index it. So I also link shared the link of the pull request in the chat. So my concern is to understand what is it doing and how is it going to be related to the plugin help scoring project. If there's any link. Okay, so the back end extension indexer is your question. And you're asking how is back end extension indexer related to pipeline steps generator. Not pipeline steps and it but the project that I'm working on GSOC. Oh, I see. Okay. All right, got it. I'm going from her lamur, if I pronounce his name correctly. So he messaged us on our project channel on Gitter to sharing the link of this PR and wondering if these would affect the plugins course or not. So I came here to understand more on that. I see. Okay. All right, so. There are, there are two facets to it. Right. So let's, it might be that we want this to affect the plugin health score but let's first let me first give you an overview of what the back did. Let's see were you here for the discussion about the extensions concept. No. Okay, so let me give you an overview of that, that way you understand what this thing is and what it's doing. The extension extension indexer takes the list of all Jenkins plugins and extracts from them. The implementations of things that Jenkins calls extensions extensions are a way that one component can allow other components to add functionality to it. For example, the get plugin may want to allow other people to add additional repository browsers, or additional. Let's see what's an additional ways of choosing particular builds. We can implement that as an extension and then declares by creating a Java class that hey this thing is an extension other people can implement, and then other people implement it and can be interesting to know who implemented extensions for this thing. So let's look at the documentation to see what I'm, let me show it live to show you what I'm saying. In the developer guide, this extensions index here is the is an index to all the extension points. And so extension points in Jenkins core and an individual plugins. Now if we look at the one I just gave as an example the get plugin we scroll down and here are the extension points defined in the get plugin. The build chooser here is implemented by the get plugin implement several, but then the Garrett plug in Garrett trigger plug in the flaky test handler and the alternative build chooser all implement that extension. So does this does this help you see what's happening here. It's this is a an index into the extension points that are implemented in Jenkins. So it gives you an higher level view of what others have. I mean, how others have extended a particular Jenkins or a core functionality. Correct. Exactly right. Yeah, so, so, yes. Yes, it makes sense. Thanks. And so, so what what the challenge was is that prior to the work of Basel pro. This list of extensions only had about 80 items in it. And what what happened is over the years, the code that was generating this page had not kept up to date with current Jenkins development. And because it had fallen behind it was not generating the list an accurate list of all the extensions. So Basel fixed that. And now we see much more than 80 entries in the list because because of his fixes. Okay. So is this what that was about about refreshing the component. So what this did, what this poll request did was this brought in Basel's changes to fix this thing and he describes it here in his text he says, let's see, let's make this big enough to read he says, there were previously 1154 failures. But your screen is stuck. I don't know is it for me. I don't know, Meg, can you see this screen is it updating. Yes, I'm sorry I wasn't looking at it but I can see it. Okay, so so dear eyes you may have to look at the recording afterwards. Sure, no problem at all. So what what Basel's what Basel's code change did is he implemented fixes for over 1000 previously existing failures. So there are 300 failures that are still there. And there were 167 new that were added because they were really old plugins and the we looked at the list and the list of those plugins they really are very old. So with that nice reduction. We got much better coverage here and good fixes over 1000 1000 additional plugins are now being analyzed. The plugins are now being analyzed that we're not being analyzed successfully before. So now back to your question should, should this, could this potentially impact the plugin health score I guess conceptually it could right because if a plugin is failing this exercise. It's probably outdated enough that something's wrong with it. Do you understand my point dirage. A little bit. So are you referring to those 167 plugins was to any plugin that fails to be processed by this tool. There's something probably a miss with that plugin. Let's, we could take an example. The anything goes for matter here is a plug in that has a failure right it somehow or other doesn't process. Now if I look at that plug in what I'll see I suspect is that it is ancient. Yes, so it has a Jenkins file, but it is depending on Jenkins 2.289. So that's about 60 version difference six months older than actually nine months or even 12 months older than the recommended version now. It's getting its documentation from the wiki. So that's not been changed. And so this thing probably is just badly out of date. It may not even compile with Java 11 yet. So it's health score would be low. And it's possible you'd say hey failure in the extensions indexer might count against it in terms of plugin health score. Maybe that'd be that's that's a fairly advanced scoring thing I think that would be a probe that we would delay for a very long time because that's much less important than many of the other things that are already on the list for possible probes. Okay. So, so if a probe, I mean, if a plugin fails for this probe and since just I'm trying to understand more. So if a plugin fails on this probe, it by this probe I mean this back in extension related probe. So that means that plugin is outdated in some way. And by some way, it could be like, it does not have Java version recommended hours or minimum based Jenkins version or something like that. So it's an indicator that there are some pre needed steps that's needs to be updated. Correct. Right. That's, that's at least that's my initial assumption on it is, if something is failing the, the back end extension indexer, then that likely means there's something about it that's out of date. Let's let's look. Let's get a first hint on the help here. Anything goes for matter. Original release was in 2012. The most recent release was just this last year. But with that kind of a gap, you can expect that there's probably not a lot of maintenance happening on this on this plugin. Yes, exactly. After a decade. Right, exactly after 10 years without a release. The release probably was to fix some glaring problem, but not really to bring it up to, well, it's definitely not up to current 4.33 should now be 4.47 or maybe 4.48 and 289.1 should be 2.332. So it's, it's at least what is that 60 versions out of date or 40, 40 versions out of date. So two full LTS cycles out of date at least. Actually it's three because there's 303 319 332 346 so it's four it's over a year old. I see. So I have one last question on this. So, if back end extension index if passes for a plugin. What does this, what does that mean for that plugin. It means that the plugin source code is well enough formed that the back end extension indexer can read the extension points from it. It's about being the code base updated. It's, it's about the, I think it's about the code being modern enough that it can be compiled with a modern, a modern environment. So by modern here I mean Java 11. And, and a recent Jenkins version. So are those the only two points or they are more. Oh, I'm sure there are more I don't know what the others are. Maybe when when fixing something like that. It's, it's a process of discovery to understand this is broken. Oh, and this is how we fixed it this is broken and this is how we fixed it and I don't know all the, all the problems by any means. Okay, so for the problems which were only happening due to Java eight being there. So you would have updated it to 11 and then back end indexer would have generated the index points for that plugin, right. That's the hope, right. Sure, that makes sense. So as per you, this would be like an advanced probe, which we need to explore later right much later. Correct. This, this is not, this is not enough of an impact on a user to be nearly as important as things like our depend about updates being used and processed. Are J is the Jenkins version reasonably current is the parent palm reasonably current is spot bugs, not disabled. You know is spot bugs allowed to run those kind of things are much more valuable I think for users. Okay, sure. That makes sense. So I think that's it from this topic. I'll also go through this page that you opened up extensions index and try to understand more. Thanks for the central. Yeah, although I wouldn't do Raj, I would not worry much about considering this thing. It's, it's such an advanced topic. I don't think we will get it into plugin health score for several years probably. Oh, okay. I just don't, I don't see it at being that informative to anyone. If something has a problem. Okay, there was a problem. And it's so the list that you were showing it does not show all the plugins because not all of them have extension points defined within the report right. That's correct. Yeah, so, so for example, this plugin embeddable build status is one that I maintain. It actually does have implementations of extension points, but elastic access plugin, another one I maintain isn't in this list. It elastic box is the closest thing to it. That's not it. And that's because it doesn't implement any extension points because it didn't need to. Okay. I see it's like, it's not a very general kind of probe. It's like very custom to relate to very specific set of plugins. Correct. Okay. Yeah, and that that makes the probe even less interesting, at least to me because to say that, Oh, you don't have any issues with extension points may mean you don't have any issues because none are implemented. And if none are implemented, why should that be considered a plus or a minus they're just not implemented. Now if it fails. That's that's that might be an interesting data point but again I think that's quite advanced. Yes, as you said it's not something relevant from a user's perspective. Right. Exactly. Yeah, that makes sense. Great. Nothing else on this topic. Thanks a lot for explaining this all to me from basics. All right. Well, and if you want to look at at the, when the recording is posted of Europe office hours from about 12 hours ago. I tried to give the similar explanation so we'll get this recording posted and Europe office hours posted, probably within the next 24 hours and you could refer to them for more details on this concept of extension points. That sounds awesome. I'll definitely watch the recording. Thanks. Great. All right so mag back to back to the issues. You have one more new issue. Good. Let's look at it. Okay. Architecting for I can complain about any documentation. Good. Good. Yes. Give me a minute and an open window, you know. Okay, good. That that section the first thing is hardware recommendations, and then it talks about architecting for scale, which references hardware recommendations. I think it should be. And there it needs to be edited through I was sitting there half listening in, but there's some examples of some editorial changes. Okay, yeah, let's see. It would have almost been easier to open a PR and fix them to do this but you're looking for good first issue so. Okay, so what you were recommendation recommending was inside scaling issues architecting for scale. Okay, good. Inside scaling issues. The architecting for scale section, which is this one that's second in the list right now should be before the hardware recommendations, I think. Interesting. Okay, now, and tell me more about that I tend to think about hardware before I guess architecture even should precede hardware. Okay. I'm going to go well and I'll show you open heart architecting for scale. It's going to reference it's sort of an introduction. In there it's going to let it's going to reference the hardware section. Okay, so agents controllers. Oh yes, right there. Okay. You're if you go into scaling for Jenkins, then to tell you what what you're architecting for and one of that is hardware. And I think that makes sense. Okay, so let's let's take that should be before hardware recommendations. No, that's the wrong link hardware recommendations. I mean it's there on the left if I'm looking for hardware recommendations I can still get to it. Absolutely. I don't have to read architecting first but if I read through an order I should read architecting before hardware. Mm hmm. That makes sense. And then I they need to add it but I count a few things there that I just marked. Very good. I had control seed that link to put in here and then I didn't put it in. No, that's great so let's let's put I think this one's good first issue because I think a novice could do this do you think that's okay. Yes, absolutely. All right, good. Okay, so we consider can continue our quest for good first issues. Absolutely. So we we had reviewed page one I'm going to actually jump to page three for now. Okay, let's look at any of these that might feel like hey which one should we look deeper Japanese translation be good for somebody who's a native Japanese speaker. And now what would that mean. See, yes is. Yeah, this is proposing a full Japanese version of the site. Yeah, we don't want to market but. Yeah, I'm not ready for that one yet. For me that's so big. And we actually we don't have a place to put it. So, right now we've got the Chinese site that is actually relatively un-maintained, and we've got the English site. Yeah. Now this one manage global settings pages to the plugin tutorial. I'm not sure. Oh, no. Well, do we have. Go ahead. What was your question. So if we have a section on that in the main docs. That shouldn't be hard to insert that into. Yeah, the problem is now this is this is fairly sophisticated stuff. Yeah, that's not a simple thing. Okay. So, so I'm, I mean, someone with strong Jenkins skills might be able to do this. So I might be willing to give it the hacktoberfest label. I certainly wouldn't be willing to give it the good first. No, nevermind. Yeah. Okay, so I'm going to go ahead and see if there was, but because some of the tutorials in general should be somewhat duplicating information that's in the other in a certain cases. So there might be a subject that's missing that you can say, here's your source material. You know, extract an appropriate amount of that for the tutorial. Right. But this wasn't one of those so. I don't think so. Now, however, let's look at this one. A user reported. This one I think is is reasonable to for a good first issue so there's a the groovy hook scripts page. They said hey, it's using all uppercase the word hook. There are exactly two things that it could be either a knit or boot failure. Okay, I use something symbolic when you could just say hook. Couldn't be there in it.groovy.d or boot failure groovy.d. Right. Good first issue. Yeah, I think so. Okay. All right, so now back to our main list. Don't you also want to add hacktoberfest to it. We've been using we've been using them as disjoint sets. So good first issue is, is easy for a first time user and hacktoberfest is you need to be an expert you need to be skilled with Jenkins. We may we may have to do add the hacktoberfest link to to good first issues but we think good first issue stand alone right now is the choice. Right. Sure. Keep going at manage. Okay, this one redirect the launching agent from console from wiki to the dock site is if we give the right description it certainly is a good first issue. Great. So it is just a redirect. So, so if I open this page. No, it didn't. Okay, so it didn't go there so it should redirect though to here. Yes. Okay. So the instructions say, this is not a page to migrate let's do an edit here. Page to redirect redirect to the destination. So the terminology update. Wait a sec, but it says there is a 3511. No, he says that has to be done first. So no, I'm not willing to do anything with the 2511. Well, and yeah, it says it was merged. So it's done. So it is done. So this one that can be removed actually. Yeah, there's no reason to put that dependency in there. And this isn't actually making any textual changes so we don't need to do a terminology update. This is inserting a redirect. And so we don't need the migration tutorial. They just need to send a PR to this particular file. Where to go. What did I, there it is. Send a PR submit a PR and see past PRs for examples. Do I need to include it probably good for the reader if I include a copy of a link to some previous PRs. That didn't work Jenkins info. That's nonsense what pages that. Okay, so this this needs to the to the wiki to the wiki configuration file, redirect configuration file. Okay, so needs needs that additional text. I'm going to dare to put the good first issue on it. And remind myself that it needs more needs triage. Okay, so that'll remind me to come back and look at it. We have run out of time on my clock. So what else that we need to touch on before we close for the for the day. Very quickie. I got mail that you're having a gradle class, the day before DevOps world. You're having gradle training. Okay, if you skip to page four. We have 3689 and 3690. Our have plug in release page does not have gradle equivalent might mark those at October fest. And maybe somebody involved in the training would like to do those. Okay. So, you could even ask the trainer to give a plug for it in the class for October fest. And the nifty t shirt you could earn. Good. Okay, so, so this was so I don't know how to do a release with gradle. So that's an interesting one. And what you're saying is, this is easy to do. Yeah. Okay, let's, let's try. Wait a second. Yeah, let's try it. Okay. Okay. Okay. Okay. Good first. And see if somebody's willing to take it on. Good. All right. And what was the other one you said, but there were two of them right together. They're too great. Oh, these, these look like they're the same. Right. Aren't they both of them are saying on the. Oh yeah. I got one. They were, I thought there were different things, but yeah. We have the same issue too. But yeah, forever we've had requests for example, pipelines that included gradle. Should find out who's doing this gradle class. Right. Yep. See if they'd like to join us for hot. Anything else make. Nope. If I get a chance, I'll read some more. I'll see if I can file some more bugs for you. Great. All right. Thank you. Thanks for joining us. Thanks for joining as well. Everything going well with you. Yes. Yes. Everything.