 Welcome to Doc's office hours. It's December the 6th. Remember we abide by the Jenkins code of conduct. So let's agenda topics I had I've got some news that I wanted to share. Weekly change log PR review modernizing a plugin blog post. Meg any topics you want to add your topic you want to add. No, I'm good. From my side as well. These looks good. All right. Okay, so I am make you had asked before. Hey, can we link to subsections. Inside of the plug-in site and Gavin Morgan has made it happen. Oh, bless him. So notice what I just did. I clicked the hyperlink that has an embedded ID on the end of the hyperlink. I jumped all the way to the page and the hover here shows me the link for it. So I can get to it. He has, he has done it and it now works at least in all the cases that I've tested. So good. This plug-in works. This plug-in used to work anyway, and it still does. Oh, does it? Oh, no, no, no. Oh, dear. Okay, well, that's, that's a serious problem. Because the navigation is now broken on this one. I'll have to. Okay, time for a bug report. That's okay. So, bug group. Interesting. So I click that. But it doesn't have, but it does have the hover over it. Interesting. Wait a second. That's really strange because the change log does have it. So that homework works, right? Yes, but, but it's reworked the, the links from the adoc with plug-in dash content dash prefix. But of course the ASCII doctor, the adoc generated hyperlinks internally don't have that. So I'll just, I've got to report a bug. That's, well, thank you for letting me test it live in front of everybody. And now let's, let's go report the issue. And if I remember, there is an improve this page. Help us improve this page. Okay, there we go. No, that's not the one I want. I want. Okay, so he doesn't have a link to the plugins. Oh, here we go. Report a problem. There we go. And this is a bug. Okay, so, whoops, I don't know. No, that's reporting a problem against the plugin. That is not what we want. Okay, so we will have to go here. And. All right. So new issue. Okay. Contents table of contents links. Sorry, do you mind if I do this now while we're on it? Thanks. Broken in a doc pages on plugins site. Okay, so plugins that use. Use adoc format. And embed a table of content, a computed table of contents. Like the good plugin. No longer resolve internal links to sections of the document. When clicking the entries in the table of contents. Okay, so, okay. Whoops. For example. The configuration, the enabling J get link. In the table of contents uses the. Enabling dash J get. Identify ID. But the ID on the section heading is actually. Okay, the links work previously. Don't work any longer. Can be converted to mark down if needed. But a doc was easier for table of contents. Initially. Okay, issue submitted. I have a question. So how, how did this used to work previously? With or without the plugin content prefix. It worked without it because if we, if we open this page on the get actually let's, this is, this is fun because it's impressive how much Gavin has done and how wonderful the work is he does. Here is the GitHub page. Now, if I open the read me here. Notice that it's got the table of contents items and these hyperlinks work. Even though when we look at the source code. There is no table of contents. All there is is this table of contents macro that causes a doc to generate the table of contents for it. So, so that's this magic here of this talk macro is the thing that I I liked about a doc that until GitHub did their extensions wasn't available with GitHub. It is now available with GitHub. I've just haven't made any transition to switch this from a doc to, to mark down. Did that address your question. Deraj. Yes. Yes, sure. Interesting. So we've reported it. Now we can, we can go on. Yes, that's great. So please to announce that 2.319.1 is released and with our changelog. Thank you, Deraj. Thank you, Meg. Thank you to Kristen. Yay. And the next release is scheduled two weeks later than the typical time. It would have normally fallen on December 29th. And December 29th is a time when I intend to be on vacation personally, it's my end of year holidays. And, and others may be doing the same, although Meg, you should be in holidays right now, right? Yeah, they're, they just ended. So. Oh, okay. It's a minor holiday. Right. It's not a high holiday, right? So. Right. Yeah. So great. But the whole world goes on holiday. Yeah. End of year is. So, so. Second week of January. Second full week of January, we will deliver a new release of Jenkins. All right. Any other news anyone else needs to share. Yes, I want to congratulate you for being in Jenkins. I want to congratulate you for being in Jenkins governance, governance board and being Jenkins documentation officer. Oh, yes. Thank you. I did not know this. Congratulations. Yes. Well, okay. Shame on you, Meg, for not voting for me. If you didn't know about it. That means you didn't vote for me. I apologize. And yet you won anyhow. Exactly. So in, in the little community where I live, we just had an election for a person in our local government. That was decided by literally one vote. Out of thousands of votes, one vote was the difference between the two. So, so Meg, it's important that you vote next year. It is. I do apologize. So the road, the results blog was created by Gavin Mogan. And yeah, it announced that. Thanks very much. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Thank you very much. That's, that's very kind of you. All right. Ready for the next topic. Let's go to, to review the poll requests. So I have not looked at this at all. So this is completely unvarnished. Ununprepared looking. So. A developer one that are right now we got to make notes. So changes. Changes after delivery. To the end of the list. Okay. And that was. 60 146014. Okay. All right. Then another one, 6000. Also moved to the end and. Okay. And this one. 6000 for looks like it needs a. A hard stop and some additional work. All of them looks like they're developer category. So far. Yeah. And so let's. Let's keep looking then. All right. So then. Let's make a fix to the one that we can. All right. New tab. Github core. Give me a poll request. Okay. So. Edit. Okay. So no, don't know. Okay. Developer disabled form. Element path and unit test by default. And I don't know that that belongs in the. In the change log or not, but I guess. Let's let's call it. Yes. For now. What do you think? I don't think it's worth mentioning. Because developers probably do care very much about it. This next one. I would propose we do a skip J and our POSIX patch for revision. I don't think generally is worth mentioning. So I propose to declare it a skip change log. Okay. And let's see if there's any comment that said. Nope. So I think they would not object. Good. All right. Next is five, four, two, three, deprecate fingerprint storage. Use the extension API instead. That seems reasonable. It needs to move to the developer section, but it's. Oh, except we like to put the word developer colon at the front. Don't we. Yeah. Okay. So let's. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. That's a good point. It should be. We probably should convert it so that it looks like Java code and looks like code instead of. Instead of the, it looks like a Java doc reference there. I mean, we could, we could convert it into. Or into a, into just code. Do you have a preference like a reference, but we need to do extension API also. Yeah, but I think. Well, oh yeah. Good point. Right. So. But I, I like to say, I like a link on those things myself. Yeah. Well, so let's, let's. Let's do it. Why don't we, I mean. Yeah. It seems reasonable. And if we do it like this, Google will help us. Fingerprint storage. And this. And the method that's being deprecated is get file fingerprint storage. Okay. Okay. Developers should use the extension API instead. And now. Let's see if we can find the extensions. Extensions. All right. No extension points. Okay, here we go. Extension points defined in. No, see that's not, I really want. Oh, maybe it's in fingerprint storage. Extend fingerprint storage. External fingerprint storage, maybe. No, no, wait a sec. I just made a mistake. It was right there on the page. This extension points defined in Jenkins core. And here it is fingerprint storage. So I think we could make it link to that. And we'll have to check it with Daniel to be sure. That's another advantage though of links is because people get careless with terminology and if you've got the link, you know, you're right. Right. Exactly. Okay, so. Everybody okay with that and we'll have to check it with Daniel. It will need a separate edit later. Add references. For the fingerprint storage. Storage API deprecation. So this link should work. Which it does. Good. And this, oops. This link should work. It does. Okay. Okay. Good. All right. Next six zero one zero improve logging from abstract. From termination of cloud agents. Okay. To me, that looks pretty good. Oh, except we don't use past tense. Right. It's supposed to be present tense. So, okay. And which I would say logging for rather than logging from, is that just me? Okay. Yeah, that makes sense to me. Yeah. Okay. Good. And then. Five nine four nine fix appearance of table tool tips. Okay, so. It needs a hard stop, but are there other things that we should be changed there? Okay. So tool tips for build intro became a little janky. There were strange artifacts in the corners of the tool tips. So is this a regression? Yeah, well, yeah, it's a regret. It's a change from the, yeah, so a regression from the. What do you call it from the, the table changes. But if you look at it, I'm not sure I'm ready to highlight it as a regression. It's no, it's a, that takes a very fine eye to detect a difference there. Let's zoom in on that. Notice, notice when he says a little janky, it's really hard for my eye at least to see that there's any change there. Yes. I guess it's a little bit of a change. Okay. Yeah. What kind of changes that even I'm not able to see. So if you look, he says there are strange artifacts in the corners and borders between rows disappeared. And I think the strange artifact in the corners, if you look at this one, it's got a different, where is it? I'm not sure I can get close enough to it. It's got a sort of a more white little bit section here. And this one has an odd shape. And I think, I think that's what he means when he says a little janky. I realize that's very precise technical term and you're all deeply impressed at my ability to pronounce that technical term. Indeed. All right, so fix appearance and then these others are all. Let's make them big enough to read. Okay, so just scan through those with me to see if you see any that you think should be highlighted that part. Yeah, these look, these look like cleanup items for me, dependency updates and cleanup items. So it's fine that they're not included. And what do you mean by these checks, checks because there's a lot of them. So a check style check is a, is a static analysis check that's configured to look at the formatting or the text of the source code. So a check style does a, does a, has some algorithmic sanity checks that it applies to, to source code and there are things where it looks, for instance, this super clone is probably that when doing a clone, we must call the super. Or if you've implemented finalize, you must call supers finalize. Those, those are the kind of hints that you get from check style. So these are, these are just static and static analysis checks that can help the developers not inject things that might be questionable. Okay. A good example of this, an easy one to understand is this unused imports. If I have an import statement in Java code, but never reference anything from it, there's no reason to have the import statement. So it's like similar to the pilot package. Yes, yes, yes. In fact, in fact, it probably predates pilot by a few years. So yes, but it's like pilot. Awesome. That makes sense. It's also like, like for, for Megs and my, as a real origins, it's like the lint command. Yeah. Or if you're more recent, it's like GCC worn all or sea langs worn or they're all sorts of warning, warning generators that will help you try to write better code. Right. That's great. Okay. Everybody okay with that so far? Yes, that's good. All right, then let's get regenerate it. And we do that by going to core. And the actions. And here we say change log drafter go. All right. Okay, next topic then. So modernizing a plug in the blog post and tutorial. Let's spend, are you okay if we spend some time there? Deraj and I had time during last week's Thursday office hours to talk about LTS and LTS processes. Are you okay if we take this topic? Deraj or were there LTS related things that you wanted to discuss further. This topic. Yes, let's go with this. Okay, great. Okay, so. One of the challenges was how do we make a prototype visible for others to review and Gavin Mogan. Has offered a offered digital ocean. Hosting of a prototype site. If we want to use that. I was Mark was just going to copy. Copy files to. To my public web server. And I'm okay with either. I Gavin's will probably take a little more effort, but would give us something that's much richer and could be used by multiple people. And you don't have to maintain it. Well, this, this will only list live. The thing that I would do would only live for the duration of this pull request, right? So maybe another week or two. Right. Whereas what Gavin suggested might be usable. For any pull request and give us a chance to see. See the pull requests and how they look. Which would be very nice. Yeah. So we needed to have between these two options. Right. Or is it decided. Yeah. So well, it's, I'm not sure it's there. They're not even music mutually exclusive. We could do both. The thing here is if Gavin's willing to do it, that's, that's a very attractive long-term solution. And. Can do this. Almost immediately. Right. This is a few minutes work. So I think what we should say is let's just plan on plan on doing, I'm going to plan on doing this one and we'll ask Gavin if he's willing to do the other one as well. Yes. Sounds great. Okay. So where it will be is what I propose is we'll put it at home. Mark weight net slash. Chill. Wait slash. And now I've got to go look to see where it's at. So here we go. Oh, wrong. Wrong computer. Sorry, just a minute. There it is. Okay. Yep. Okay. So. I propose to put it at. That location. And right now that location is not useful. But it will be useful reasonably soon. So what it has is one file in it right now, but I'll put more. We'll just put the site there and see if that works. Cool. Okay. So the, the more important thing is show the two of you, the kinds of things that are in the document now. And some of the things that we've, we've discovered while working through it. Mistakes I've made things like that. That are, are good things for us to be sure that we understand, particularly, as you and I are working together on this. We need to, I need to clarify the things where I made a mistake here. Watch out for it. So the, the live stream videos are still very useful. And. Highly effective. We absolutely want to embed those. The thing that I had done was I've added a number of additional ideas of things to be done. And some of them just don't make sense. So let's take as an example. This enable check style reporting. Is allowed. But notice this caveat. Check with the maintainer before enabling check style. The reason for that is check style is very noisy. Default settings. Of on check style. Are so noisy. That they're useless. So it requires. Requires. A custom check style definition. That the maintainer. Agrees is useful. Now, now you may say, well, wait a sec. We just did this review of a bunch of Polarik. We saw a bunch of pull requests in Jenkins core that are using check style. Right. We that we just saw those and it mentions those. So how can it be that it's, and what's happening in core right now is. Basel Crow is adding. One step at a time. Check style checks. That. Let's, let's find some. Here we go. This one. And what he did is he added some source code to it. And he added some source code to it. And what he did is he added some source code changes. And then if we look carefully. We'll see. He added an explicit, very specific. Add this check exactly this one check. Right. And that requires negotiation with the maintainer. Right. So, so putting this in some, in a general. Place like this is just too. There's too much interaction with the maintainer for this to really make sense here. Right. We could, we could, but what I think we might do based on that is we might move it into the section on. What do you call it? After you've adopted it. Because after you've adopted the plugin. Then yeah, it may make sense. You as an adopter may choose which check styles. It may make sense. Okay. Because I was saying that this. Instead of the way it's currently written, it should be. To create to whatever, enable this thing correctly before you call it. I'm okay. I'm not sure what you mean. You're saying don't use it unless you get with the. Maintainer. You know, in other words. Define a custom. Check style definition. Or. That the maintainer agrees on. Before using. Check style reporting or something like that. That's rough. Yeah, there you go. Okay. So. Agree. Decide with the maintainer. Or maybe it's identify. The useful. Subset. Yeah. Check style checks of check style. Warnings. That will help. Help the plugin. Without. Undo. Noise. And then we use that to say, hey, justify the fact that. Default settings are so noisy. They. Aren't helpful. Right. Now, do all. Maintainers know how to do this correctly. I mean, we've got a lot of new people stepping up and saying, I'll. Adop that one. Yes. Do we tell. Is there a place we can link that tells people how to do this. And that's a, that's a good hint. I would say. Maybe what we would use is location with. Examples of effective check style rules. And of useful check style rules. And there I would point them right now. Use Jenkins core as an example. Because it's where. Where. Basel Crow has been doing example work. So. Let's put a hyperlink to it. And we will just that way we've got it. I don't know that that needs to go into the tutorial, but I think it's worth. Now, where would he have put? Check style. Dot. Check style. Maybe. Just a minute. Okay. Back to the poll request. Sorry. Just a further minute. It is. Oh, it's right in the palm file. Okay. Good. Even better. Yes. Here we go. Now the challenge is I don't know how to search for that text. In a hyperlink. So we'll just make it a permalink for you. Okay. I mean, it's. Typically with a tutorial, there's some place it's got more detailed information on quarter cases that you can say. For all the options go there. So maybe this is something, maybe we need a separate section on defining check styles or something. Yeah. Well, or choosing which ones you'll use. Right. Because what. What this is saying, you'll see what this says. It says, okay, here are the check style rules. We're going to do line length. For any file that ends with Java, we want lines to never exceed 240 characters. And we'll ignore. Certain lines. That are known to have. Tendency to be long. Right. Right. But, but this is, this is a useful example. Of, Hey, here are some. Interesting check style rules that can help. Right. Yes. Okay. All right. So that was, that was one thing that we learned from, from John Mark's working through it was. I added this one as well. Div based form layout conditionals. You remember, dirage that one of the things we did was, please update the base Jenkins version. Yes. And because we did that. And because we choose a version 2.289.1, which is after the tables to divs translation, it means plugins that had added this, these conditionals. For tables to divs can now throw them away. Because they now say, I no longer have to even run on the, I can't run on versions older than this. And that means everybody has tables to do. So for instance, I remove these from the get plugin. Okay. Yup. That makes sense. Now let's go back to some. That are there. Oh, this one. This is another one that. Enable the project mess detector. It's. PM, PMD. And it. It's again, one that is, it's like check style. That it's default settings are so noisy as to be unusable. But if you were to tune it, it could be, it could be useful. So this one also requires the person to interact with maintainer. Right. Exactly. Yeah. So I moved it into this section because I, if, if I received a pull request enabling PMD on one of the plugins I maintain, I would most likely immediately close it and say, sorry, we should have had a discussion about which things matter and which things don't. And, and because many of them, it would be, it is so noisy that it just, it's not useful. Then. What else? Okay. The others. I think so far we're seeing things. They're okay. Oh, okay. No, there is. Meg, you remember, you remember. She called Africa. This one. Is, is a major area for work. That. Hey, it doesn't, this text doesn't nearly describe. Well enough. What. What can be done to improve. Online help in general, but especially for pipeline. File naming patterns. And the techniques to test. Online help. After adding it. This is not generically pipeline documentation though, is that this is for the steps specifically for the steps. Good. Yes. Very good. Yeah. That's a good, good clarification. Yes. Improved pipeline step. Documentation. Yeah. Very good. Yeah. Good point. Thank you. Yeah. And, and the thing that was complicated for me was. It's it by convention. The file names, the, the help is located based on a. On the name of the class that's referring to it. And if you don't get that right, and put it in the right place, it just won't be found. Right. Okay. So. Oh, and this is one that I had fun with. Oh, seriously. This was fun. But this is clearly after adoption. Okay. So there is a thing called the pit mutation framework testing. What it is, is it's. It takes your tests. It takes your Java source code. And modifies it so that it should cause your tests to fail. And then gives you a report telling you how well your, your tests did at detecting the injected failures. Oh, and, and I think it is, if you've got something that is very mature with the, the very, very well covered with its test automation. This thing is the next level of. Are you really as well tested as you think you are. Hmm. Dr. Professor Uli Hoffner of the technical university of Munich. Pointed this one. But it's, it's really. This one is so interesting. Because the plugin needs to have. Significant test coverage already enabled. And I would put this very late. Like, yeah, like right there at best. Because it's so, so exotic. Right. All right. Well, so I think I've been through the ones that were on my mind. Did Raj, were there any of these where you feel like, Hey, you would like to take one or two of these and, and describe them further. I, I've got to get started writing on this again. I haven't touched my, my commits for, for weeks. And I need to get. Just make more progress. Yes. Same here. So. I don't have much question. So I just wanted to know that you were mentioning this person, John, who pointed out these things. Right. So is he doing it with Jenkins or, and how did he find out about this draft? Yeah. So John Mark is, is a colleague of mine at cloud bees. Who is a new person in the team that I manage. He's doing developer relations and part of his ramp. Up is modernizing a plugin following these instructions. And so, so he's, he's acting as our first test case. It's very nice. And I also saw some other mentions of people who are. Good to review this. Right. Somewhere. Right. Yeah. Well, and I keep, I keep pointing people to this document encouraging them to, to give us pointers and give us help if they'd like. Okay. That's great. So other than that, I don't have much question. We'll work on it. As soon as we get new things here. Sure. Great. Okay. And that's me is I've got. I've got. Discuss the changes and what we've learned. I guess there is, there is one more thing that. Well, it's, it's related. It is that. Sometimes when people read this document, they may think that this was from somebody who really knows what they're doing and everything in it is absolutely correct. And what Jean Mark observed is not only is it not correct. Many of the things are correct. Right. Like the check style thing that I did. I had put it. Put it as, as though, oh yeah, you should do this. And he looked at it and said, that's, that's crazy. We shouldn't enable check style because it's just not helpful. Unless you turn unless you intentionally tune it. It will actually hinder you rather than help you. Right. Great. I'm wondering about these things just structurally. These are like these long laundry lists of all sorts of good things. If it would be better to group them. So you had, you know, They're kind of all over the place, but I, there's definitely, there's a lot that have to do with testing. There's a few that have to do with documentation. Right. And, and I don't, I mean, I don't know. Cause I haven't done this. Maybe there's a, I don't know. There's a few that have to do with documentation. Right. And, and I don't, I mean, I don't know. Cause I haven't done this. Maybe this laundry list works, but I'm thinking whether it would be nice to have. You know, getting the testing right. And you could go into all these things. Yeah. And, and I don't know if, okay, this is a private document that Jean Mark did. I'm hoping he won't mind that I show it to other people. He, I think he, he, he would agree strongly with your question. Yeah. I think it's a good observation, Meg, that we should categorize these things better. Yeah. And so here's some categorizations that he used. He had a topic he called general. And another one that's code quality checks that I might call static analysis. Okay. Another one that is code improvements. Another one that, and another section that is. Documentation. Let's see. Let's get this view so that we're not in print layout. So let's go back to the configuration. Another is configuration. I might, I might put one here as. Yeah, see, I'm not sure. This one is that one. Yeah. Well, see, these. These configuration things for me are special cases of. This mutation one has to be there. They're actually testing, aren't they? Yeah. They're testing this kind of configuration. Now, now there's another category here, which I think what would be the things you can do as a maintain, things you can do as a contributor. And things you can do as a maintainer. And they may be different. Right. For instance, this one. This one is. Maintainers. Only maintainer. Yeah. You have to have after adoption, not before. I can't imagine you've got enough tests in most of the Jenkins plugins to make that useful. Right. So can you scroll down? Sure. So there's already a section for maintainer. Oh, yes. Oh, good. Right. Let's put it there. Very good. Thank you. So let's put that down there. So should the, the check. Stuff be under the maintainer? It should. Yes. Absolutely. Because that's. This one. And this one both really are maintainer things. Right. And they're maintainer things because you got to decide what you actually want. So there was a comment on this previously said that opinions differ about this. Exactly. Okay. That's the reason the reasons the opinions differ about it is because there are people who correctly say, don't you dare enable that on my, on the thing I maintain. It's too noisy. I do not want to waste time addressing its non useful reports. So that's why I would say that, you know, I would say that ideally all maintainers would define the stuff so that it is giving useful information. Well, or, or make it explicit. Don't, don't bother enabling it on this repository. Right. Saying, look, I've considered this thing. The get plugin is one of those where I've considered check style. And I would never mean to never enable it. I just wouldn't. So it actually should be. You know, I would say that the next day somebody knows it's not, you know, this person did not enable it for this reason. Right. Exactly. So, so, or, or you need to, what did you call the thing that you do where you actually define the check style test that you want? Yeah, that's, that's where you, you define a custom check style definition. Yeah. See, I would like, I might say for this one, it should be. I think it's a valid concern because there are things that can be quite wasteful in the output. If you have to, if you waste time worrying about code formatting, that is irrelevant to you as a maintainer. You've spent time on something that didn't help you. Oh, okay. Yeah. Yeah. That would. Yeah. See, I think, I think Jesse, Jesse Glick's argument was, Hey, he's not even sure that people should bother using check style. And, and, and I think it's a valid, it's a valid concern because. You've spent time on something that didn't help you. So that's why you should, and then why can't I retain that for, you should define anything you want checked for by check style or that you don't want it used for this. Right. And where should I, and if I want to say, I don't do like for you, Mark, if I looked at the plug in, where would I know that you had deliberately decided not to use this. Right. So that's where, that's where. I'm going to declare in the contributing guide that check style is not being used. Is intentionally not being used. Right. And maybe what that is is a list the static analysis. That is used. And note the static analysis that is intentionally not used. Right. Oh, and now that you remind me there's, there's one more thing which we should have put in there and I never did. And we've got a video on it and everything it is. This is a whole new thing which is enable find sec bugs, which is a spot bugs extension. And enable find sec bugs. Enable spot bugs extension. Find sec bugs. And then it's see the video that Jeff Thompson did created to show how to enable. Find sec bugs. For additional spot bugs static analysis. That is security specific. Let's get a link to that. Jenkins find sec bugs. Jeff Thompson. Video. There we go. See, you knew that was easy. In your hands. Yes. There we go. But that's, that's again a place where we could embed this into the page. And it, it's a 40 minute video on the. Strengths and weaknesses of find sec bugs. So. Be it how to enable it. Right. This task of man and maintainers list is getting long too, like that needs subdividing. Sorry, which maintainers list is that oh, the one that you had on that your ideas. That's when John Marx list. Right. Well, and this one might be might be subsetted again into the kinds of, you know, documentation versus so release drafter is really a documentation thing. We might call topics labels and label assignment as sort of pull request automation. And then this one is security. These are static analysis. Plugin security checklist. Yeah, can. Yeah, so it would it might be possible to break these also into into topics. Yeah, in this in this categories. Good. Great. Because I mean, I look at this and it's sort of confusing because it's just all these individual parts. There's nothing that puts them together. And does using it and categories like this does that help you better? I think it does. I mean, it's it puts it there and then you write into it, of course. Okay, to me. So are we going to make two different blog posts for the first part and for the maintenance part? Or it's going to be as we decided in one blog post only? Oh, that's a good, good question. Yeah, it may be that what we say is we should that's a very good idea. If we said, Hey, let's do the week if we focused our efforts first on the contributor section and admitted that the maintainer thing will come later. Uh huh. That would get us content faster and a subset of the content that's still useful. Right. It's also a good thing for us to have as we enter Google season, a Google summer of code, because these are the kinds of things that Google summer of code students could jump right into and say, yeah, I'm going to do this as a way to become familiar with the community. Exactly. You know, a Google summer of code student could adopt a plugin and make these changes as their way of introducing themselves to the community. Yes, even I tried that blog post where we interact with the plugin. Right. Make a plugin with Hello World, right? Right. So this would definitely be very helpful to them. Good. Very good. Okay. That first one under documentation. Is that complete? I mean, if I make my, if I put my documentation in the read me of my source code, I have my documentations under GitHub. There's, there's more to it than that. I figured there was, but, but it's not, not a lot more. So what it is, is you, you take, you need to do two steps and the two steps are described here. The first is what you do is you, where is it? You create the documentation. Where is the mention of Palm dot X and oh, that's shameful. Oh dear. Okay. So this needs fixing. This page only tells half the story. So this talks about how you migrate it. That's, there's got to be another page that talks about it should be to the GitHub repository where the plugin code is correct. It is. That's correct. Yes. So, hmm. Okay. Just a minute. Hey, come on. The word document occurs. Whoops. Oops. There was one right there. I saw that's it. This one is the one that I wanted. Yes. Okay. This is the better choice because it describes how you do it in order to make the thing work. Right. So that, that page that we're at earlier is, is imperfect at best. This is the one that let's edit this and correct that. So what it says is using GitHub as, as documentation source you create a read me. You modify the project URL in the GitHub repository and that is, is a crucial thing. And then you release the plugin and it's takes all three steps before you've made the conversion. All right. So that other document, should it just have lose a whole lot of text and say follow the instructions over here? Yeah. Well, this plugin wiki pages is describing this thing needs a complete rework because the, this Jenkins wiki exporter is no longer useful because the Jenkins, the Jenkins wiki is gone. There's nothing to export any. Oh, okay. Yes. Okay. And so, so this page and maybe what we should just do is report an issue for this page. Okay. Plug in wiki pages page describes non outdated steps. The page describes wiki conversion that is no longer necessary, no longer available. And in many cases no longer necessary needs to describe how to use the archive site, how to use the Jenkins wiki docs, docs archive site and the Jenkins wiki read on static HTML site. No screenshots to offer. And okay. Agreeable? Yes. Yes. Okay. So when we open this page, it says yeah, good. Okay. And then here's the reference down below. That's still a useful one. And this one is just a link to the exporter itself that Gavin's eventually going to turn off because it, it really isn't, it doesn't have any source to convert any longer. So I could, you know, if I, if I paste a URL to the con the Jenkins wiki here, it will just fail if I remember correctly. Good. Nice catch. Okay. Oh, we have hit our time. I, sorry for being so blathering on here. Any other topics we should just discuss here today? No, nothing from my side. Okay. Continue. Oh, actually, let me make a note here. That was an important thing that you noted is a plan to publish in two phases, contributor topics, maintainer topics seem reasonable. Yes. Because that, that lets us get the content out sooner. And let's do Raj and I both focus on the early things for first, first intentional work. Right. Do we want to mention the desire to get this completed for before the summer? Yeah, I want to complete it before. I want to complete the first phase before end of December. Okay. Yeah. So you're going on holidays. So that would be before Christmas, right? Correct. That's right. So before December 25. Yes, absolutely. That's nice. That's nice. Yeah. That may be a stretch, that may be a stretch objective. It's admittedly, I'm notoriously optimistic about how much I think I can get done when reality is much harsher. Yeah, please take it. I didn't mean it that way. No, no, that's great. All right. Anything else we should discuss today? No, nothing from my side. Yep. Good meeting. Thank you very much to everyone. Recording will be available later. Thanks a bunch. Bye-bye. Bye-bye.