 Welcome to Jenkins documentation office hours. It's the 13th of May, 2022. Topics I've got on the agenda, news. Google summer of code, if Chris joins us, we'll put this down a little further just in case. Sheikot Africa contributon, Jenkins LTS baseline selection. And actually maybe we should just put those in news. And Java 11, we'll just leave them there. Required Java 11, internationalization and localization meetup. And I don't think I've got anything to say on the backlog other than awkward embarrassing things. So anything else you want to add, Kristen? No, no, I think we're good. Okay, all right. Well, so Sheikot Africa contributon, we are one week from the end of the project, one week from the end of development. So we'll stop development and switch to writing final reports, summarizing the results, et cetera. And we're going to use community.jankens.io to host those for those final reports. So it's much more approachable than making them do a blog post. It will also be a final blog post on Jenkins.io, but that's a thing I'll create, not making them go through the process of creating an ASCII Doc blog post. So really cool what they've done so far. The inclusive naming project has swept through probably 20, 30, maybe 40 plug-ins looking for references that can safely be changed and submitted pull requests to many of them. The screenshot updates project likewise has done quite well, especially given how challenging it can be to get screenshots to the correct location in order to take the screenshot. So both of those have captured enough information that we can continue the work. So they're well suited to, for instance, Hacktoberfest. Oh, okay. And that's a nice result is even if there's, we're not all the way done in this project, the fact that we know how to continue them is really good. Right, right. Now the pipeline help project, unfortunately, was just as complicated as this year. Too complicated for next year. We won't try that again. It just, it needs much more senior experienced people. It takes me sometimes hours to figure out how to do some of these things. And so we just can't put them through that again. So it's, they've done good things. They've learned many good things and they've contributed and that's a positive. But really, we like the projects to be, give them a feeling of, hey, we did really great stuff and here are a number of pull requests we submitted and this one had too many blocking issues get in their way. Sure, okay. Now, next, are any questions on Seacore Africa? No, but it's interesting from the helpline, the pipeline help, the helpline, pipeline project, the pipeline help project. Is it gonna, is it also like, I'm just trying to think also, I mean, yes, it's like trying to get people who are maybe new, but is there a better way that we can encourage people who are maintaining their plugins in general to provide better pipeline help? Like to think about it as a first order. Yeah, good question. I'm not sure really how to encourage that or maybe if there are people generally aware that it's on the site and that it is visible and that it could be made better. Documentation is sometimes hard to remember to do. Like properly and full, but it is sometimes as a user, difficult when you know, you go in and even in the generator to click, like, you know, the steps and then it click the help and there's nothing really there to describe what the different steps are, but maybe that's a good idea, like the plugin health project, but that would be a really good idea. That's likely now, now this is for me, this is a relatively advanced one because it would mean looking inside the source code of the plugin, identifying pipeline steps and then identifying and it doesn't have help. But nonetheless, I think that's a valid thing to consider, hey, if a plugin does not have help, we should first identify that it doesn't and then guide people this is how you do it. So I think that's a really good idea. Yeah, interesting. Oh, cool. It's good that it could be, even if it's something like a restructural, but it's like something that we help drive plugin developers that they should also think about making sure that that's useful for people. Yeah, well, and I think we could, we could also include it in the contributing to open source document, right? Where, hey, here's how you do this, but in order to do that, we've got lots of places where we need to learn how do you do that? And that's embarrassing for me to admit, but there have been several times where the participants in the project would say, hey Mark, we found something that doesn't have help, where do we put the file to add it? And my attempts to find the place to put the file failed. And it's like, oh dear. So I'm sure it's possible, but I don't know how and I need to do research with somebody more skilled than me to find the location for this thing. Where does this help belong? So yeah, I agree. It's a good thing to do, but part of the hints here is some of the times the reason the help doesn't exist is because it's not obvious where to put the help in order to make it visible. Now, many of them still are, hey, we should give more examples. We should do things with, sorry, just a minute while I mute my... Oh, sure. Got it. So anything else on Chico to Africa? All right, next topic then. Jenkins LTS baseline has been selected for June. It's 2.346 will be the release and the release date has been moved from June 1 to June 15. We intentionally took a three-week delay choosing the baseline and the release officer has approved a two-week delay in the actual release date. So that's a positive for me. It gives us a little more time to be sure it's stable, healthy, et cetera. Kevin and I have started the upgrade guide and the change log and found some topics that there's sort of some themes involved. UX improvements are the major theme, really a big deal. It looks much, much, much different. If you look at weekly.ci.jenkins.io, you'll see just how different it can look and feel. Notice the icons over on the left here and the design library gives us all sorts of cool views of oops, wrong one, this one, to show the different things that we can do with it with buttons, for instance, with symbols. So a bunch of different iconography that's being used and more and it's got experiments where you can try, hey, I'd like to see what do modern radio buttons look like and how do I call them out in the jelly files? How do I do this and that? All sorts of elegant things in the UX improvements. The upgrade guide, the biggest one is this removal of PNG and GIF icons. It means some older plugins need to be updated and really old plugins may not render correctly because they depend on an icon that no longer exists. Interesting. So working on what you might call the long tail of plugins with outdated references. Any questions on the June LTS? Okay, next topic then, require Java 11. So the Jenkins project is planning to end support for Java 8. Right now the proposal is that May 31's weekly release will no longer support Java 8, it will be Java 11 only. And then the LTS in September will likewise end, actually final date is still under discussion, but May 31 looks probable for weekly and then September 2022 LTS for the first LTS version that requires Java 11 or newer. And we're seeing a bunch of, well, there are a number of items going forward that are further Java 11 fixes and improvements like the Jacksby library has some surprises in Java 11. And so there's an epic working on that right now. Any questions there? Okay, next topic. Today we had a localization and internationalization meetup and it reminds that we need better documentation on internationalizing Jenkins and its plugins. There are some things that we discovered and but as a result, we've now got this really elegant site that makes it much easier to translate Jenkins. Crowdin.Jenkins.io provides a translation support site to allow people to submit their translation. So here, Chris Stern has submitted Chinese simplified and Chinese traditional translations for this plugin. Bruno submitted for French, Alex for German. Okay, my Italian isn't really great, but it's good enough to fake. And we're seeing already good results and this plugin has released with the changes because it's using continuous delivery. Well, that's awesome. It was, it released actually during the webinar. So we merged it and then said, oh, yes, here it is, the release is done. Well, that's so cool. So still lots of work to register plugins with Crowdin, internationalize them. And localize them, right? There's, this is not, this is just the beginning of work, not the end, but it's really kind of cool to see what's happening. Any questions there? No, but I will say that's really, really cool that you're able to see it release with all the changes during the webinar. It was, it was so cool. Great to see a plugin release happen automatically after we submitted, after we, and it's really three stages, right? And that's, that was for me, it's exciting to watch the three stages. There's the translation stage. So that's a native speaker. Then there's the proofreading stage where somebody else reads it and says, yeah, I think that's a good translation. And then there's the maintainer merge. So this proofreading generates a pull request. So the maintainer doesn't even see something until it's been through both translation and proofreading. Oh, cool. Which is, is a relief because I don't speak Chinese, right? I don't read Chinese. I do not read, I don't reliably read German or French. And so, so it's, it's really nice that they've got this proofreading step that's a natural part of the tool. Right. All right. That's, that's without Chris here, I'm going to just skip over Google Summer of Code unless there's something you wanted to note there, Kristen. I do want to, like I did want to say, I really, if there were, there were a few projects that maybe like were interesting Google Summer of Code. I was really hoping that we would be able to maybe in the future, devote some of the stocks hours or even the other one. If, if one of those projects does end up being chosen to just kind of be able to talk about it in the meeting. And I know that sometimes there's pressure, has to, you know, have to sign on formally to do the mentorship thing, but it'd be nice to have the student if they are part of a program or the project ends up happening, like to be in the meeting and hopefully be involved and get some feedback. So I was hoping that people in this call would be able to help and then have that community support. So, yeah. I like that. I think that's great. Yeah, agreed. So certainly if, because we had, we had multiple docs related project ideas, right? There was the pipeline steps doc generator. There was a, there was a project idea proposed for automatic screenshot generation. And I think there were, there may have even, oh, rest, automatic REST API generation was also one of the, one of the ideas that was suggested. So any one of those would make, make very good sense to be in this meeting. Right. Good, yeah. Yeah, and it's, and has that ever, like just don't, there should be no pressure. So, like for, you know, anyone that they'd have to do anything, just some reviews or help, encouragement. Right, it's good to, good to be involved and help with those. Right. As a, as a docs team. Right. Because, hey, it's in our best interest to work to be sure that those things look good. They're going to be on the doc site. Very good. I like that. Thanks. Now, what's the, what's the timeline there? Is it end of May when, when Google announces? I know that they have to announce the spaces first. And then after that, I think the org admins choose. Yeah. And then, and then there's the period of like no communication type deal. And then Google makes the announcement about, yeah, like then Google announces with projects for select eggs. I remember there was also, yeah, see the, Yeah, there it is. So May 20th. There we go. Yeah, actually, wow, look at that today. Today was a slot request, but I know, I know that there was the whole thing about like, it's offered to certain students, but like, you know, there's always a chance that they maybe they did multiple projects and they have to like choose per, so I knew it wasn't like an immediate thing. And so, okay, so we'll just, we'll find out on the 20th of any of those projects were accepted by not only Jenkins, but also by if the students, you know, cause again, like the student maybe, who knows how many projects they even applied to. So that type of deal. Like if they're, if one of the projects is chosen, we'll find out on the 20th, but I would love to make sure that they, that the students comes to our meetings or maybe like, you know, even looks over release notes, just to kind of get a little bit into the whole thoughts about Docs. I agree. Well, and your question is perfectly timed because May 20th they announced and May 20th starts community bonding. So there's no delay between the announcement of which projects are selected and community bonding starts immediately. So we could have somebody in this meeting on conceptually May 20th because this meeting is a, well, I don't know that they will have a, no, it'll be May 20th, 1800 UTC. Yes, I was like, oh. So that means it'll be one week later. So we may want to do a special meeting where we say, hey, as soon as they've announced, we're going to schedule something to welcome all of the Google Summer of Code contributors and talk about how Docs works for them. Yeah, that'd be cool. Like as I'm looking at my calendar, I was like, oh no, it's like the, I'm out for like that particular week. Of course, at the day, like I'm out of the office. I was like, oh no, I was so worried about this. But I was like, but I'll definitely, yeah, it's like to be online and I'll be able to email but unfortunately I will not be available for a meeting on that day. But if we do something with Docs. Yeah, I mean, we could say, hey, welcome and we could schedule a, or maybe ask the Org admins to schedule a welcome and we present, ask Org admins to schedule a welcome meeting. And then the Docsig presents something to help, to help them get started on the Doc side of things. Yeah, because even for some of the other things they're working on it would be helpful to, it would be a good thing for them to also remember to do Docs for any project. Right, that's the, oh, what do you mean? What do you mean you created this great project and failed to describe how to use it? Users are going to grumble at you. So here we're here to help you remind you that documentation matters. Yeah, good, good insight, very good. Well, and we've, I've got office, Google summer of code office hours that starts in about 40 minutes. So I'll join that briefly and suggest the idea because we're only, we're only a week away from the announcement. Excellent, good idea. Any other suggestions on Google summer of code? I thought that I could think about this time. Okay, all right. And because I'm not going to humiliate myself by showing the backlog of pull requests, I propose we call today done unless you've got some other topic. Nope, actually, do we want to ever like take, I mean, not today, but like any other, like maybe we just like pull a pull request and we put it on our agenda and say we want to work through this one on the next meeting or... Sure, we could do that. Okay. I know some of them are really old. Like some of them are hard. And I know that's like, I don't know if there were any easy ones that we could like. Yeah, right, right. Well, I can show you some. Okay, it's like, it's too much to just do, like, you know, just to look at, but then also just like the, oh, maybe we need to just... Well, so let's, let's pick, let's pick some of the most scary ones, right? Because there's some really, here's one, support the Maven Groovy Source Directory. This is the single oldest one, September of 2019. And as far as I know, it's the enhancement is not done. Oh, okay. So this was proposing to document something that is dependent on this pull request that has never been merged. And given that it's not been merged now in almost three years, I think we could safely close it. But in fact, let's just take the initiative and do it. So closing the pull request for now, for now until we open after it merges at when the feature is merged. Excuse the cough. All right. So because really it's not helping us being battled. So that one, Victor created it, but until we get this, until we get this merged, it's not, we shouldn't publish that doc. Okay. So now we're on a roll. Should we look at another one to see if we could close another one similarly? Yes, and maybe if it's something easy, we can close it. Yeah, let's do it. Right. Okay. Let's see. All right. So here's one. A draft from Oleg mentioning contributors. Yeah, so then it's like, but a draft from this long ago. Maybe. I don't, I just, I mean, Oleg's not actually able to contribute. And so I think let's just admit that. And is this something that we wanted to do and the change a lot? Cause that's another thing, right? I see. I would like it actually. I think it would be pretty, it would be very nice to have mentions of contributors. It's a good way to highlight them. I like it when GitHub does it with theirs, but it would require additions to the data. And I think closing due to inactivity is probably the most sensible thing to do. And if can reopen in the future, if there is interest, right? Yeah. Good. All right. Let's, hey, let's try one more. We may get. I like this. I was like, yeah, sometimes, you know, it's just the little wins, right? Well, and yeah. Okay. So this one I'm not willing to close because the internationalization is a topic that I actually need, but there are lots of proposed changes in this and lots of things that need rework. So it's, go ahead. And now with the new, it might be outdated even already. Right. Now with the new stuff that you just said. Exactly. So there are, there are plenty of things that this would benefit from a, let's get it published because it will help us, but let's do the publishing after we've made sure that it's accurate and reliable and matches current behavior. Okay. Yeah. And I liked the old likes observation. Let's not using a new thing. Let's just get rid of the bad content, the old content and put this in. So yeah. All right. I propose we call that our progress. Yes. I like this. Thanks, Kristen. Thanks very much. Any other topics before we end for today? Not that I can think of. All right. Well, thank you. And talk to you again next week then. All right. Thanks, Mark. Bye-bye. Bye.