 Cording starting. Welcome everyone to the Jenkins Docs Office hours. This is the European US hours on November 17th. Today we have Mark Wade, myself, Bruno Verracken, and Alex Brandesis here as well. Welcome to everyone and thanks for joining. On today's agenda we have an action item about switching the docs mailing list. Some information to share about the Jenkins elections. Some talk about in a conversation around the documentation officer duties and what that means. Just a couple updates on the next LTS and weekly work. And then a couple items about next Thursday, Thanksgiving is in the US, so status of docs office hours and another blog post that'll be coming out. Is there anything else that anyone would want to add to the agenda today or does that cover things for today? Alex, were there any specific topics you wanted to bring? No, nothing new to the agenda. Okay, great. Thank you so much. So the first thing is that the doc's mailing list needs to be archived and switched over to the community.Jenkins.io site. That is something that I'll be working on with Mark as we transition into the next term of Jenkins election winners. I don't know how to say it, but yeah, on that note though, so the Jenkins elections have been officially announced today. What this means is that we do have all new board members and officers and because each role only received one nomination, everyone's a winner. So congratulations to Alex and Ulrich who are now new board members for the Jenkins governance board. And for officers, Tim Chacon will be staying in the release officer role, as will Alyssa in the events officer role. Wadek will be staying on as security officer. I will be joining as documentation officer, and Damian's going to stay infrastructure officer for the next term as well. So first and foremost, big, big, big, thanks to everyone who participated, made their voice heard and shared nominations. Couldn't be done without you. And even as much appreciation to the candidates for confirming, accepting, and graciously stepping into the roles, officially everything starts on December 3rd. But due to the nature of the way the elections worked out this year, we have our answer already. So once December 3rd steps in, we'll look at the transition and sharing between current and former officers and members. That does, of course, mean for the registration and candidate nomination are closed. And we still have a community discourse fed for the election. But since we're not technically having actual elections this year, yeah, we've, it may not be as useful as the blog post or any other community point for getting information. But community fed is there. It's always available. So we can always discuss more on there or talk about things in the discourse thread. Yeah, Kevin, let me add something to that. Maybe you should add that to the blog post that we don't have elections like last year or the year before. In case someone asks like, where do I need to go to vote? Because last year and the year before we used a third party service for that people may be familiar with. And if we don't do that this year, people may be confused if they need to vote. Where did they cast their vote and so on. Right, right. And typically we'd be using the condorsate voting system from Cornell. I did check with Mark about this one and he did share that in the past when a particular role receives one nomination, an election is not required this year. We have that exact situation happen for all the board members and officers. So that is spelled out there. But if there's some more detail that could be added or some additional clarity that could be provided, I'm more than happy to help do that in any way. So yeah. So Alex, do you think that's enough or this description is enough? Would you prefer we do something right? We could, for example, highlight in the LinkedIn post, hey, elections are complete and the new officers have been elected. Yeah, for example, I mean, to be fair, I just read the post right now. I didn't give Kevin's PR I read before. But yeah, we could add something to LinkedIn. Because this paragraph is pretty clear to me. But if someone else didn't read that yet, we can link them there. Yeah, and we can definitely like we still have to I still have to propose the tweet and LinkedIn post to be submitted. So we can definitely say specifically, you know, Jenkins elections results or something like that to signify that there is not a voting period this year. So yeah, definitely, definitely agree on that. We can definitely make that more clear. So yeah, thank you very much, Alex. Is there anything else that you wanted to share or add on for the election stuff or is that cover things? That's it. Okay, great. Thank you so much. Yeah, and I may message you just to double check on the wording that I suggest for those posts. So I'll follow up with you directly if I have any questions. Okay, wonderful. Then the next thing on the agenda is just going over the documentation officer duties. So Mark and I were talking earlier, we wanted to just go over this, review what the documentation officer's purposes and a little bit about what they do, or I guess what I'll be doing over the next year in my efforts to help maintain and keep up Jenkins as best I can. So Mark, as far as this goes, do you want to start? Do you want to just kind of have an open conversation about it? Sure. Yeah, well, if everybody else is okay, if Alex and Bruno don't mind listening, as I talk through the topic, let's do it. Okay, great. So Bruno and Alex, the idea here was let's go through and get a recorded session that talks about what are the duties of the documentation officer. And I captured these items as places to discuss. That way Kevin's got it and we've got an archive and then Kevin will put it into the Jenkins site so that it's documented officially there. But this was an easy way for me to share the kinds of things that I did. And then he can put those into the documentation. And it's for reference for the next documentation officer in the future. So as soon as we can spot Kevin doing something which is not in this part of the video, we can document that too. Yes, exactly. Good to talk. Yeah, okay. Very good. That's correct. Yeah. So there are several areas, right? Jenkins documentation site is one. Jenkins releases is another. Those are the two big ones for and then there are certainly sub topics under those, but those are the two big ones that were on my mind. If others have other areas of documentation, certainly interested, but those were the key ones for me. Oh, I take it back. Let's put one more, Kevin. I really should. Okay, this is wiki to GitHub migration progress. But this is not fair. It should have been written before the election process. Absolutely. Because for for Kevin is just being dumped on now. Isn't he? How did that happen? Yes, right. Okay, so wiki to GitHub migration project, track the progress, encourage contributions. And then I guess there are others which I would call advocacy projects like Google summer of code, Google summer of code, Google season of docs. We're to choose to do that again. She code Africa contributon. So those are also part of the responsibilities. Good. And I actually think it was every that messaged me in the last week or so to asking like if that's if they can just ping me and let me know when documentation is needed so that I can assist there. And I just want to put that out there as something that's that falls in line with all of this as well. If there's anything that doesn't have documentation and feels like it needs it, I can constantly be reached and I can always help with that. So if you do come across anything, let me know, submit feedback. I am checking the feedback sheet that we have. So yeah, anything that we might be missing or need. If it's not something that we can be readily improved by fixes, we can add that. So yeah, good. Excellent. Okay. So shall we are you okay, Kevin, if we just go through this piece piece by piece, because I think it's worth us doing a record, including in the recording. So let's start all the way up at the top, the Jenkins documentation site, review, refine, update and merge pull request. So click that pull request link. That takes us to you're already doing this and you're already comfortable with this. What this means is you are a member of the the correct group that allows you permission to merge. So for instance, pick the automated change log for 379, that one. And if we look at the bottom of this one, it says merging is blocked because we haven't had any approval yet. So let's for the for the fun of it, you're going to approve this one. So go to the top. Eventually, you're going to have to approve it. So now add your review. They approved and you could put a comment temporary, whatever, right? And we won't merge it. We're just going to see that the button. Notice you've got the green squash and merge button. Other users don't get that. So that that proves you have the permissions you need to do this test. So now go back to the Google Doc. Okay, review and act on issue reports. This is we track issues with the documentation on this GitHub issue tracker. And you'll see here a list of 127 open issues. Now these are relatively mature, meaning they've been there a long time. And there's lots to do to improve on many of them. But you get to think about, Hey, which, which one should we focus on? Why should we focus on that one? So scroll down a little bit. And I'm going to show you one that is of interest to me. Whoops, right there. Up a little installing Linux page has no upgrade instructions. This is one that I think would be very, very nice. We had a contributor said I want to do it, but then it didn't do anything on it. And so I think it would be really nice for us to have instructions on how to do an upgrade. So back to the doc now. So issue tracking and pull request tracking. There's another bookkeeping effort. Click the docs issue reports on JIRA thing. First challenge is you've got to log into this site. So top right hand corner do a login. And this is your accounts dot Jenkins dot IO. Oh yeah. So maybe that works very good. So these are issues that were reported to the to the JIRA site before we switched. But what you need to do is periodically look and in the top left corner, if instead of order by priority, you were to click that and say order by create created. Okay. Because what that will tell us is which ones are may have arrived recently in the wrong location. Got it. Okay. Right. Because the other issues pages where the actual documentation. They belong. Issues should not arrive here. They shouldn't. Right. This is not the place for documentation bug reports. But if they do, we wouldn't want to lose them. Right. Okay. And so would I then take one of these and create a Jenkins like a GitHub issue for it? If a new one arrives here, you could you can the first choice is ask the submitter. Hey, please could you send submit this as a GitHub issue instead? If they don't do it, then you could do it yourself. Okay. Right. I can. It's actually easier for most submitters to submit a GitHub issue than it is to submit a JIRA issue because their GitHub issue, they're already using their GitHub account. In order to submit to JIRA, they have to have a Jenkins account. Got it. So one's a little bit easier without having to have this Jenkins account. Correct. Right. Okay. So let's go back to the to the. So next, now we're getting into the place where we may see things in the recording that are uncomfortable. I apologize if someone's offended. Click that page that's open it. And the reason I say it may be offensive is sometimes people say things or write things in this that are really rude and and rude to the point of, you know, foul language, profanity, et cetera. So if you'll, if you click in the top left-hand corner and then you use control and the down arrow, it'll jump all the way to the bottom of the sheet. No, no, you got to click the timestamp field. Sorry, the timestamp cell. Click inside the cell A1 and now do a control and the down arrow. Oh, maybe it doesn't work. I'll command if you're on the Mac maybe. Ah, right. That makes more sense. You've got that funny operating system. Sorry. Right. So, so what this is is we've got, we've got on every documentation page on, or almost every page on Jenkins.io. We've got two links. One report an issue. If they click report an issue, yeah, go there. Very good. So jump to the bottom of this page. You'll see here improve this page or report a problem. If you click improve this page, it will take you right to GitHub. Good. If you click report a problem, takes you right to this. There are some of the pages, however, that have a survey on them. I remember, for instance, the was this page helpful? Yes, there it is. That one. If you click that one, if someone fills in this field, it gets published, the results of that gets published to this spreadsheet. And so sometimes you'll get a useful bug report. Sometimes you get insulted. That's cool. Right. Sometimes you get people saying things that are really, really foul, right? And you just have to ignore those. Don't be offended by them. Just ignore them. Yep. This is completely anonymous feedback. And if you look for various forms of profanity, you'll find them in this file. That's not the objective, right? The objective is see if there's something useful that someone's provided. And usually then you'll transform that into an issue on issues.jankens.io. Right. Or by hand. No, no, by hand. And I only do it when I find there's something that I think is so valuable. Yes, I would like it there. So how many of us are monitoring this file? Two. Me and Kevin now. Okay. Yeah. This is a Docs Office for Responsibility, so no one else needs to review it. Right. And we don't expect anyone else to do it, right? This is publicly visible because Kevin's accessing this and I didn't certainly didn't give him any credentials to access this. So anyone can see it and it can offend anyone. And this does go back to 20, like the very beginning as well. So it goes back a very long time. Beginning is a little too strong, but yeah, it goes back like four or five years. 2017-ish. So there's a lot of stuff in here too that also may have been taken care of already or fixed. They know that there was some blue ocean stuff that was not helpful back then, but now might not be relevant or resolved either way. Exactly. And this is not a page we worry about updating, right? It's just a log of people's comments. And if sometimes the comments are helpful, we use those comments. And if they're not, we just keep going. For instance, the page you're on right now has a complaint about the Git plugin. And that was what motivated me to do a much better job documenting that plugin. So there are times when this inspires us. There are other times when it just infuriates us or angers us or makes me mad or that kind of thing. And sometimes people are nice and just say it was very helpful. Well, and we don't object to that either. It's just most of the time what we really want is their negative feedback, not their positive feedback. Yes, very full is not very helpful, but it's encouraging. It is, yes. Okay, so are you comfortable with this page, Kevin, in terms of what you do there? Yeah. All right. So the next next one down there is create documentation that when you've already been doing it with your additions to the Blue Ocean page, with your additions of screen of videos that are relevant to particular topics, you add those relevant videos in. And I think the users, we've got good evidence based on click counts on those videos that the users appreciate that. So keep doing that. Okay, great. Good to hear. Now the next one is improve the site structure. And this one's one where you and I will have to coordinate it in the most recent governance meeting. If you'll open Jenkins.io as a site, we'll talk about what the problem is first. So here on this page in the top sort of right hand side, there's the subprojects drop down menu. Okay, leave that up for just a minute. Notice there are some things on that list. Let's see, for instance, have you ever heard of the Jenkins operator? Maybe not, not too much. Do we really need a top level entry for Jenkins remoting? Probably not. The document Jenkins on Kubernetes project was over about two years ago, so it should probably be removed. So this needs some cleanup. All right, so that's one place that needs a little bit of pruning. Now go to the community drop down that's right next to it. Notice here that there's another list of six or eight things, advocacy and outreach, documentation, Google Summer of Code. Some of these are inactive. Others are are still very active. But what the governance proposal was is, hey, let's, let's switch from this concept of two different things, subprojects and special interest groups to one thing, working groups. And we'll put all the working groups under the subprojects menu and call it working groups and remove them from community so that it's just working groups. And there we'll have the platform SIG, the advocacy SIG. We'll have Google Summer of Code. We'll have any other short-term things we create can go there so that community becomes a shorter menu item and what would become working groups is about the same size, actually, but a little more fluid. Right. And it's basically, it's making sure the community chat is focused on the community aspect of Jenkins and then having the subprojects, special interest groups. I mean, from a new person perspective, it doesn't seem like there's too, too much difference between the two. So condensing that all makes sense. Exactly. And that was Gavin Mogan's point in governance board was really, and Oleg Nanash have agreed, subprojects and special interest groups are many times indistinguishable from each other. We can't tell what, why is something a special interest group and not a subproject? Why is something a subproject and not a SIG? Yeah. So that's a task for us, but that's a structural thing that you and I will have to coordinate and because it changes the top-level menu, we'll need to be sure we bring Gavin into it because he has a web component now that does the top-level menu bar and he'll want to update that. Right. That everything will have to be aligned at that point with the web components being separate on the page. So. Exactly. Okay. So back to the document. Yeah. Okay. So then now this is one where Alex, Alex is deeply involved here and has been a lead on multiple Jenkins releases. So review, revise, approve and merge the weekly change logs and the LTS change logs. We've got the LTS 2.375.1 with Alex as the release lead and he'll need a change log and an upgrade guide. So you and I will work on that next week to get that prepped and ready to go. Alex, I assume if it's ready by end of next week, that's soon enough for you or do you need it sooner than that? That sounds good. The release candidate went out yesterday and the final release is scheduled as usual, 14 days after that. And I think if we will have that by next Friday or Thursday or end of next week, we have definitely in good shape to release point one in the week after that. Great. Thank you. Okay. So then let's see the... Oh, so Jenkins releases. I think actually there, Kevin, you're pretty comfortable with that. Any questions you wanted to ask there? Honestly, no. I've been working on the LTS and change logs for a little bit now with under your guidance, of course, and working with the release leads on the past few and the rest of the developers. I feel pretty confident about that and comfortable. And I know I can reach out to Alex if I have questions on this one or if I want to double check anything on this case or whoever the release lead is in the next one. So, yeah, no, I feel pretty confident and comfortable with the Jenkins release stuff. So, all right, good. So then let's go to the next one, the Wiki to GitHub Migration Project. And let's be more clear, Plugin Documentation Migration Project, right? So this is specific to plugins, not to other forms of documentation. If you'll click that hyperlink, track the migration project. And then so what this is, at the top of this, we see 892 plugins still need to have their documentation migrated, but 946 are done. Now, the nice thing here is we've got a tracking project that we're using. This is sort of a different experiment. So I'm going to link to the tracking project. So, Kevin, you can get to it as well from here. If you scroll down past something that says, okay, look for something that says PR merged. Oh, right here. Click that. Okay. Here's the poll request. This poll request is in merged, but not yet released. But if you look on the right hand side of your screen, Plugin Documentation Migration Wiki, click that. That is a GitHub project that tracks these poll requests. So it's a different technique, but it's been a, well, for me, it was an experiment to see, could I use GitHub projects to get something useful out of it? And it's sort of been useful. Right. But what happens here is when a new poll request is created to propose, to migrate documentation, I will typically click the plus sign above the in progress column. So click that and paste the URL to that poll request and then click add. You don't need to do it now. But what that would then do is now that creates this entry that it's connected. And so now we'll get status reports. Okay. I thought it was entirely automatic and I was scratching my head. How did he do that? So no, it's partly manual. Oh, thank you. It's not just partly manually. It's entirely manual. Prefer that. It's embarrassingly manual. And that's, I'm sure there's a way to make it not manual, but it just wasn't worth the effort. So for me, it was, yes, let's put that. So, and in terms of if you'll go back to that, that report, I think, let's see, which one was it? That one. Yeah. If you, if you look at this from the high level, we're making really pretty good progress because as you, if you start from the top and scroll downward, you see that the the high volume plugins, plugins with more than 100,000 installations are generally all done. Just keep going down, keep going down. And whoops, let's see. Whoa, back up. Okay. So here we go. No, even so deprecated. We don't have to worry about that. So, so before we get to the first one, we're already down to the 30,000. So less than 10% of all controller installs, before we get one that, that hasn't been okay and merged and released. So, so that's, that's encouraging. Now, there's, there's still a lot to be done. The, the, when a PR is open and not merged, that usually means the plugin is abandoned or up for adoption. And, and that's what you see here, right? The Ansible plugins pull request was opened, I think two plus years ago, but it's, there's not been a release. Yeah, just over two years ago now. Yeah. So, okay. Is there, I know this would be the separate page, but is this coincided with any of the Jenkins reviewing issues and stuff like that? Or this, these would be separate because they're plugins. So I wouldn't, we wouldn't actually receive pull requests for these directly. You won't be notified of a need to review these, although you certainly could, if you wanted to, you could review the pull requests and comment on them. So when a PR, if you, if you scroll up to the top, you can sort based on that status column. And so then it will group all of the search for PR open. So here they are, you could go review these pull requests to give your comments on, on these proposed pull requests. Do, as far as I can tell, it hasn't inspired or prompted or helped anyone when I've done that. So I've not bothered. I've, if, if a documentation pull request to a plugin doesn't get merged pretty quickly, it doesn't leave me very hopeful that it's going to be merged anytime soon. Right. And so, so these are all the pull requests that are, for instance, so open or merged, they would have to be addressed by the plug and maintainer though. Correct. Or someone else would have to adopt the plugin in order to, in order to merge it and then release the new version of the plugin with it. Okay, got it. So, yeah. So in my head, I was thinking this might coincide with reviewing the Jenkins issues or what was the other one, the pull requests, but these are going to be separate from what I would be seeing on those. So. Yeah, for me, it's actually quite different. It's quite different because you have so little control over this one. Yeah. All you can do really here is report status. Okay, got it. Okay. Great. So then on the next topic, advocacy projects, there it's trying to watch for and encourage people to do good contributions, documentation-wise, for Google Summer of Code, she called Africa Contributon. Those two are top, top of our list because we've done them multiple times. Google season of docs we did once and it, the management overhead for Google season of docs was large enough that I'm not sure I'd lobby we do it again. It just, it had, it had more, there was more work hiding in it than I was ready to do. Okay. And then would Hacktoberfest be another advocacy project? Oh, Hacktoberfest. Oh, yes, absolutely. And that's, that's certainly a very popular one. Yes. Making sure. Thanks. I know the Google Summer of Code 2023 proposals are, or those are being looked for right now. I think we just actually had a blog post yesterday about it. So yeah, and I do want to actually participate in that and be a mentor as much as I can. So I'll be sure to reach out to Jean-Marc and Alyssa about that. Or Jean-Marc, I guess. So yeah, no, and I've been doing, I, I have participated in Helps with Hacktoberfest just the last month and she called Africa as well. So it's another thing I'm fairly comfortable in at this point. Great. Those are, those are the, the collected topics that I recognize. I'm sure we'll find more. And as we find more, we'll, we can add them to the list. Yeah, definitely. And I'm sure that as I go along, I'll have questions that you might not have thought of either. So we'll figure it out together. Yes. And then yeah, and like I had mentioned earlier, just to make sure that it's on record that if anyone needs help with anything, please just reach out to me and let me know if there's someplace I can change or affect in any way. I'm more than happy to help and to collaborate. So any, any ask, no worries. I will say whether or not I can handle it and then figure out the best way to go about doing it. So and then I think this is something, the, the benefits there, I think are things I've already been noticing. Like we have more clicks on the videos in the documentation, like you stated earlier. And just I want, I want to continue to encourage people and empower the community as much possible to participate however they can. So yeah, I mean, my goals are aligned with the benefits of it. So great. That's all that I had. Great. Yeah, I think I mean, I'm on the same page with you, Mark. I'm really excited and really happy to be getting going on this. Bruno, Alex, did you have any other questions or concerns that you wanted to share or anything? Concerns. Maybe you're going to be very, very busy, I guess. That's okay. Sorry Alex. Go ahead, Bruno. I'm done. Thank you. Okay. I just went over the list again. You have a bullet point called viotically checked for misplaced docs issues on JIRA. Is the website project no longer intended to be used on JIRA? Because if that is the case, we could just archive it so that new people don't create issues there. Yeah. Interesting suggestion. The experience I've had has been that people don't submit. Well, and we saw it in Kevin's query. The last submission to that project was April of 2022. So I think it's already well enough hidden. I'm not sure that we want to go through the risk of archiving it with the risk that that may hide things that we'd like to keep publicly visible. So, Mark, do you know if there are still links somewhere that can lead to the JIRA issue tracker? How will people end up at that place? I don't know of any links that lead to the website, to submitting to the website, JIRA project. And if there are any, we should definitely remove them. There certainly are still links in various locations that link to existing website issues. You know, for documentation purposes, that kind of thing. Yeah, that is a similar process is what we are doing when you're moving from JIRA issues to Github. We basically just archive the component that makes sure that the submitter can no longer select on the dropdown, but all issues and all components are still available for search or in the search query. That just makes sure that you are actually no longer able to submit new issues, but still have the track to resist existing issues. Yeah, and my hunch is that because this is a website as a project at the JIRA level and not a component, it's more difficult, I would assume, but I haven't done the research to find a way to switch off accepting any new issues in the website project. It's an interesting topic. Kevin, you could put it on the list to see, hey, should we make the JIRA website project read only somehow? Good insight, Alex. Anything else, Alex? No, that's for my side so far, but something that is definitely possible and feasible for the future. Right. Yeah, and if it makes sense to archive things and make sure that that's unreachable for users unless they get there through a separate link, like I'm more than happy to sit down and figure that out and take a look at all this sort of stuff for sure. And then I know I think there's also been some discussion about Site Generator and we've been looking at stuff like Antora just due to the versioning option that they have for the documentation. So that's another thing that I've been talking with Basel about it a little bit in the last few weeks and going forward, that's something that we want to kind of investigate further. So that might also fall under one of these. So yeah, it definitely falls under some of this stuff. So cool. All right. So that covers the documentation officer and I am super excited to be that busy. Thank you again. Last items on the agenda. So we'll have weekly 2.379 next week. I'll be reviewing that automated change log in the next 24, 48 hours so that I can be taken care of and updated either prior to merge or after merging. We have our next LTS coming out on November 30th. It is 2.375.1. The baseline is 2.305. Alex is actually the release lead. So again, Alex, thank you very much for becoming the release lead here. And as far as documentation goes, Mark and I are going to be working on the change log and upgrade guide to make sure that's taken care of, completed, and ready to review prior to the end of next week. Most likely a little bit earlier than that due to Thanksgiving here in the U.S. One last thing about the LTS is that the RC testing has started just the other day. So we are in full swing of it. And like I mentioned, next Thursday is Thanksgiving here in the U.S. So Dock's office hours will be canceled next week. We will resume the week afterwards. So just a short break. But yeah, the holiday in the U.S. is going to hold things off for us. And in that vein, we also want to have a blog post published around Thanksgiving that shows appreciation and thanks to all of our sponsors, the continued support and resources that we've gotten. We want to make sure that no stone's left unturned and that everyone we're not leaving anyone out. We're showing our appreciation. The open source community has built on this idea. So making sure that everyone feels appreciated and feels like they're continuing to perform meaningful actions is really, really important and something that I want to focus on a lot as documentation officer. So yeah. So look for that. That'll be coming out. We'll be celebrating the sponsors and going to the holiday season with a nice note. Is there anything else that I have forgotten or anything else that would like to be added? Thoughts? If not, I think we can go ahead and stop the recording. It'll be available in 24 to 48 hours.