 Welcome to the European Jenkins Docs Office Hours. This is the November 10th, 2022 edition. Today, we have Mark Wait, myself, Bruno Rockman, and Alex Brandes here. For the agenda, we have a few action items to check on. The Jenkins elections. Lots of updates there. Docs World 2022 was yesterday. We've had our weekly 2.377 release and our most recent LTS release go out and successfully. And we have our next LTS coming up at the end of November, which will be the December LTS, technically, even though it's on the 30th this month. So is there anything else that would need to be added to the agenda? So, Mark, archiving the Docs Million List. I know that that's still something that CBD stuff. Yeah, sorry, still haven't done it and probably won't happen in November. Okay, no worries. Thank you very much. We did publish the October newsletter, October Jenkins Monthly newsletter. So this has the updates. So it has the updates for all the different SIG groups for Jenkins. Documentation, user experience, platform security. So anything that we've been taking on the last month is going to be available here. And going forward, we're going to be having that available for the community as well to offer note suggestions and any kind of feedback on it. So that will be part of the newsletter process going forward. And then lastly, since October Fest has ended, we are going to have a recap blog post for October Fest. It's going to share user insights and contributor insights and stories, some stats overall from October Fest, and advice quotes and general ideas about the October Fest contributing and project and just how everyone kind of did this year. So it's going to be great and we'll have a lot of great information from the contributors. Next thing on the agenda here is the Jenkins elections. So the voter registration and candidate nomination periods are open right now. And currently we have 48 members in the Jenkins election voter group. There are plenty of more contributors to Jenkins. So we really want to make sure that everyone is aware and can join the group to join the group. All you need is an account on community Jenkins.io. You can use your GitHub account. If you don't have a GitHub account or want to use a separate account for this, you can sign up and just dedicate it to the Jenkins election voting. But being a member on the site and having an account is required. And any prior participation is appreciated, but I would still be the person would still need to register for the 2022 edition. This is unique. This is a different group. And this is the list of folks who we will then send out to the Condorcet Internet voting service so that we can proceed from there. Voter registration is open until November 17. So by all means, there's still time, please. If you haven't already, go ahead and sign up, join the group, create the account. For the record, instead of leave, it would say join here. So this looks different because I'm already part of it. But for a new user, you would have the option to just join the group right up here. And Kevin, I delighted to have Zina Dowdo with us and I just sent her a message on how to register to vote. Oh, fantastic. So hopefully the next three or four minutes we'll have 49 registered voters. I'll check it out. Thanks, Zina. And candidate nominations are also open right now. They go until November. So today, so there will be an announcement with all the candidates and their statements regarding why you should vote for them. And once the voter registration is completed, so November 17 is the tentative date that all candidates will be announced, the voter registration is closed, and then voter voting itself will actually open at that time as well. There's also a community discourse thread for this for this. So there's multiple points of contact multiple points of information. There's the blog post and Jenkins Community blog. There's the community discourse thread. And of course, we're talking about this as much as possible and all of the different office hours of meetings, and just across the board. The election process page in Jenkins has also been updated to reflect the 2022 election. So even further information there and additional instructions on voting registration candidates etc etc. Are there any other questions on the Jenkins elections or any other items to raise register vote, please register please please please. Yeah, and then vote. Yeah, participation is a big part of it so yeah. All right. So DevOps Road 2022 was yesterday. It was held online since everything got kind of remixed and rescheduled registration was available to all. It is open since it's online now, and it has been recorded. The record recordings will be available for anyone that had registered signed up. And I think you still might be able to sign up and sign in for that purpose, but the recordings are going to be available and definitely so even if you weren't able to make the sessions that they had yesterday, they're still available and this you can still see all the meetings and sessions that did get presented there. There were a lot of talks that were not able to be presented in the online format. So what we're hoping to do and looking to do is eventually reschedule those and have them presented as something like a Jenkins online meetup, or any other sort of community event that we can host. And then we can present some of these other topics that we did not get to share at DevOps World. So the plug and health scoring is one thing that we've been working on a lot recently. The Google Summer of Code participants helped out a lot with, and that's something that we definitely want to share and elaborate on, but want to make sure that we have the right space and the right means to do so first. So we've got another voice here. Zinab and I had prepared a talk for DevOps World. Zinab, are you interested in doing that talk with me as a Jenkins online meetup? You're muted, Zinab, in case you're there. Hello, sorry, I didn't get that. So, Kevin was just mentioning DevOps World 2022 and that many of the talks were not selected to be presented during the online format. Yeah, we could consider presenting them separately as online meetups. You and I have prepared a talk. Are you interested in doing an online meetup with me to share our talk in that online meetup format? Yes, yes, I am. That was actually one of the reasons I joined the session to talk about that. So yes. So, so Mark and Zinab, ZAI, ZAI and AB. So Motola will also be interested. Oh, good. Very good. So, and I'll get that inserted later and it's the talk is called open source, open source in Africa. And we'll get, I'll get more details. So that's great, Zinab. I'll look for a date, start the proposal, etc. Perfect. Now, another one on this same topic fits with Bruno and me. Is this we've got upcoming Google Summer of Code 2023. We'll start very, very intense promotion of it in the January, February time, but we could already start even sooner than that if we wanted to do a copy of the workshop that Bruno and John Mark and I had prepared, but focus it online and say we'll take up to six or up to four Google Summer of Code interested people and take them through the workshop. Record it and do the whole exercise, but it would have to be a workshop format. And that's a very different thing than a Jenkins online meetup workshop format. We would really do it in, in Zoom meeting, in a Zoom meeting, not in a webinar, and we would require pre registration and have very limited attendance. But I think it's a possible if, if we, if Bruno and others get hints that there are people who are interested in it, we could do that pretty easily. We could spend two hours with a group of four to six interested people and take them through a whole series of exercises on how do you contribute to open source. Very cool. And that's okay with what I said Bruno may say no mark you're crazy. No, no, of course, 100% yet. And that'll be separate. That would be separate from the contributor summit workshop. Plug and tutorial all that sort of stuff that would be separate. It would be it's this is a very different thing it's focused on taking for or at most six people who have never contributed to Jenkins before, and bringing them to the point where in a two hour period they successfully submit their first pull request request. And that pull request is valid and useful and helpful to the project. Cool. So it's not, it's not a junk pull request it's really a useful pull request, and they fund validations of it, etc. So it's, it's making them in two hours, make that transition from non contributor to first count contribution. Wow, really nice. That'd be really cool. I hope, I hope everyone can join up or at least share their interest levels on that because that sounds like a great time. Sounds like a crash course like I got recently. So, yep. Cool. All right. Anything else on DevOps 2022 to mention. Nothing for me. So, we had our week, our weekly release 2.377 go out successfully and the last week we had our LTS 2.361.3 that which will be the last release for the 2.361 LTS series. Last week there, Darren, Pope and Mark were able to do the live stream going over what's new with the LTS. So that's available in on YouTube. And we just had a small, a small section to go over the weekly changelog process as now I'm helping a lot more with getting those changelog entries updated and adjusted to be better presented. So, just to go over the process and Alex did want to share some insight he had into, I think it was this step the second piece here. So, Alex by all means, just let me know or I'll stop when we get to that point and more than happy to have you share what you want to share. So the first thing that happens for the weekly changelog review process is I will just go through and review the weekly changelog and verify that there are entries to change and what they need to be changed to. And then I'll create a draft pull request that's available for review and feedback that just suggests the changes I plan that I'm seeing and want to make. And once that's created, Mark may or may not apply the changes prior to it being published. If it is published without the changes I will go back in and update the changelog accordingly. Otherwise, it can be adjusted prior to but more often than not, I'm going to go back in after the fact and update things as needed. Yeah. Thanks, Kevin. That sounds like a good workflow. Yeah, that is placed properly there. And my initial question was the automatic PRs generated are basically based on the proposed changelog entry of pull requests submitted to Jenkins, like Jenkins as the core itself. Are there a lot of things you need to fix up later on? Because I've seen you creating quite a few PRs on the Jenkins repository over the past weeks. And so my question was if there's something we as core maintainers could improve to the proposed changelog entries section before we merge PRs to reduce the need to fix up for later on. So Kevin, I'm going to jump in here if that's okay. Great. So Alex, there are some things that we can do that I think confidently would actually improve it and others where people continue to ignore what's written in the file and they'll continue to ignore it. So the first what we can improve right now in the pull request template, the bullet item for the changelog entry starts with a dash. And oddly enough, the translator only wants it to start with an asterisk. So if we change that from a dash to an asterisk will reduce one place where we regularly have to make fix ups where we have to make repairs. Now the others, what's that? Yeah, that sounds feasible. Yeah, I think I think that one is and that one's one that's relatively easy to do and high probability that it will be retained. There are others where it says things like please use the imperative form. And some people don't know what the imperative and it even gives an example if I remember right but really people don't read it or or they they write something that is completely different or off. And I think the answer there is saying use the imperative form is the best we're going to get and Kevin or other writers will have to correct it as necessary. There's not much we can do to change that one. Yeah, as someone who submits a few pull requests which are not labeled a skip changelog. I can only speak for myself but I always find it hard to come up with a changelog entry that is not super in detail. If I if I mentioned some fights like in jelly or something that I did change that is not really helpful for the end user changelog. Maybe for the GitHub changelog but not for something we publish on Jenkins.io. So I always try to break things down to make them easy to understand. But yeah, you often lose a bit of information then. And and that's exactly I think the value that Kevin and other changelog reviewers bring is it's okay that the author of a pull request expresses the changelog as best they can. Kevin now comes in thinking like an end user and his extra set of eyes may help us get a better one. So I think what you're describing is an ideal process. That's fine. It's why we like that there's a team of reviewers that look at the changelog after the after the submitter does their best job they can. Yeah, I think that's needed because if you compare the changelog from the GitHub releases tab with what we have on Jenkins.io, that's always a big difference into how things are actually described. The GitHub changelog is much more in like this is much more technical phrasing on what I noticed. So yeah, Exactly. And and you're you're you're absolutely correct. And I think I think that's okay. Right. We we've we've said that we want and we like a curated changelog. And we know that for LTS releases we really have to have someone who decides what should be in or out. And so since we're going to be curating we're going to be reviewing will just take advantage of that and keep doing it. And one of the other things to ask that I've found I'm doing most than anything else is reordering the entries themselves because a lot of them will come in with the developer ones at the top of the list which ultimately should be at the bottom of the list so it's a lot of rearranging and reformatting those as I come across them so it's not it's a lot just like of streamlining it and reformatting things more than changing anything. There are some messages that I might update to reflect a little bit better like what happened or if there is a bunch of small minor things that don't need to be described like a spring security fix might summarize that part of it but definitely like honestly I'm taking a lot of what's already there and just putting it into a different place. You do make a good point Kevin on the developer changelog entries the guidelines say move those to the end and the tool doesn't move them to the end and if a developer someone who's comfortable with that tool could extend the tool to put developer items at the end that would reduce one of the things that's a fair one. I mean on the different note. I think the changelog generator picks up the developer label we put on PRs. But this is at least to my understanding only useful for the GitHub changelog because the Jenkins IO changelog has only two kinds of items like we have bug fixes and we have enhancements. We can't really highlight something as developer or like as dependency updates there only if we are prefixing them but prefix them them with developer and then the entry. Actually the the the changelog has the concept of developer and if you look at the fields that the generator writes one of them I believe is called category and developer is a valid value for that. So it actually does know about it but it doesn't present them to the user in a visibly different way we just have a working rule that if it's a developer topic we put it at the end. But the the generator doesn't do that ordering for us and it is willing to do other ordering just doesn't do that one. Yeah I meant it in terms of colors like for bug fixes we have the red one for enhancements we have the purple one and for security fixes the yellow one. Like there's no real color to distinguish between what is actually for developers or what is like I don't know and enhancements in terms of UI. And that you're correct. You are absolutely correct. Thank you very much Alex I really appreciate that again like that's awesome to be considering and thinking of and definitely helps with kind of what I'm looking at on a regular basis as well for sure. Because I want to make sure that this is what's being shared with me in the first place and what's what everyone's working on. I definitely don't want to make any changes that change the message or take away from what was actually done as far as work goes. So anything that any kind of feedback or anything that you think of that can assist with that or make life easier for everyone I'm always open to it. I think you're doing a great job on that. I occasionally review the LTS chains locks if I get the shot to if I'm the release lead but everything else I'm pretty happy with. Great. Thank you. Right here. All right. So yeah, and yeah, and we'll have the next LTS is going to be on the November 30 police. So this will be 2.375.1 so the next version we're going to be coming out with is using baseline 2.375. So this will be the start of the next LTS line. The change log and upgrade guide are needed still. So we're going to have the changes since 2.361 and backwards of anything since 2.375 was actually released. Alex is the release lead. So again, Alex, thank you very, very much for volunteering and taking over as we go to the last last new LTS of the year. Yeah, kind of not really. But yeah, really exciting, really, really great stuff. And there's a bit there's been a ton of stuff changed and fixed and added. So there's going to be a it's a large change log this time around to be fun. Great. So we got through everything on the list here on the agenda. Does anyone have anything else they'd like to share throughout there? Yeah, just really quick timing in on yesterday and not yesterday last week's and Asia Docs Office hours. I think what was it Chris or someone else brought up that the LTS checklist is pretty not much of use. Yeah, Chris. Yeah, it looks like there was a mention of like Chris being able to share kind of his release lead experience. Yeah, I would I would phrase it I would phrase it differently Alex not a not a much use it was that yes it's unclear and there are times when it's it assumes things that somebody who's a first time release lead doesn't know yes. Yeah, it's not much of use if you're doing it for a first time. Right. Agreed. Or especially if you do doing it for the first time if you are initiating the point one release line, because this one actually requires the right permissions on core repositories. Yeah. I know that the checklist might be a bit confusing. I mean, I got used to it over the past few releases. But maybe I could write something down like an actual text form rather than something in bullet lists to outline what actually needs to be done and how things need to be done. Rather than having a bullet list saying hey you need to do this and this here but doesn't explain why things need to be done. Yeah, it'll be helpful for young blood. If you're if you're willing to do that that would be great. The reason we created the checklist originally was assuming that it would help experts make fewer mistakes. So the case I'm used to the checklist story is pilot in an aircraft who spent hundreds of hours flying airplanes but a checklist assures they don't make make foolish mistakes. But it's it's not a training document. So what you're proposing. I love it. It's the idea of something that would be a tutorial and introduction or a training document. Not just the checklist. I like that if you're willing to do that Alex that would be great. Yeah, I think the checklist is likely written by someone who did those releases before and just wrote down what they had in mind. Yeah, that would be me and Tim. You nailed it and then refined by you and refined by Chris and refined by Ildefonso and Kathy Chan. Exactly. It was written by experts for experts. Yeah, we have had quite a few PRs to the checklist over the past few months updating a bit of documentation here and there making things a bit more clear. And thanks to people like Joseph Patterson who outsourced a lot of work to update CLE used in the Bill of Materials or Jcast to reduce the need to submit PRs by hand. But yeah, there's still a lot of stuff you need to do by hand and that is barely to not blind within the checklist. So I would like to go ahead and I don't know write a bit of it down how to actually do something, especially outside of running the LTS scripts. I like that. I wholehearted support for that and and thanks for tolerating the checklist and as your first experience you could have walked away and discussed and said I refuse to use this thing. Thank you very much. Yeah, my first release was actually one of the point releases after Ildefonso did that. To my experience point releases are always easier and quicker to do than initial releases given you have already a baseline to backbot stuff and don't need to initiate one. Right. Well, and we find as the documentation team that it's a lot easier to write the changelog for dot two and dot three than it is for dot one right dot one is an awful lot of thought. Yeah, thank you very much. I appreciate that. And the insights really great to hear and clearly can lead to some improvements down the line. So that covers everything that we had on the agenda for today. Is there anything else that anyone would like to share or bring up. I know I already asked but figured once again case like I'll expert anything. But once all right. So I think we can stop the recording then mark and it will be