 Welcome. This is documentation office hours for the Jenkins project. It's the 27th of May, Asia time. Thanks for being here. And we will. The topics I've got on the agenda include localization internationalization. June LTS. It's not from Kevin. The Java 11 epic she code Africa contribute on and the one we've had good success on recently, working down a few outdated pull requests. Any other topics you'd like to put on the agenda dirage do you want some time to talk about about your get your GSOC project. I think I do not have any doubts on that for now, but okay, if you have anything to discuss, then that would be great as well. All right, yeah, well, so I know that we've got the pipeline steps doc generator. Oh, actually, maybe that's a place for us to ask. Let me put it here as sort of at the end is meeting time flexibility in case we need it. Okay, so that's one topic for me any other topics to add to the agenda. We can add the change logs or what about that. No weekly change logs we rely on people to review them during the week or review them on Monday. So, we've got the LTS change log that we we certainly will discuss but weeklies, we rely on reviews I guess I guess I do have one more item which is next week's meeting. The next one is Mark is out of the office, playing in Eastern US. grandchildren, right. Children actually a child, not grandchild. Ah, child and his wife and we're going to go have fun and he's going to show me his Jenkins installation that okay, let's stay on topic mark. All right, so anything else that needs to go on the agenda. All right, so next key topic here on localization crowd in is progressing. No, I believe no growth in on number of a number of plugins on the site in the last week. So need to internationalize. I've got an example in the priority sorter plugin. That I've just completed and Darren Pope and I intend to do another contributing to open source modernizing a plugin session, this time on internationalizing a plugin. Any questions on localization internationalization and internationalization. Okay, GSOC projects. Kristen you want to share brief description of the pipeline steps doc generator and what the plans are there. Sure. So, um, one of the one of the projects. Ian is working or beyond is working on this for improving some of the more complicated steps for the doc generator, including mostly the infamous stage or I think step. One of the ones where it takes like, it's very poorly displayed so we're a bit part of it is really a decode so he's going to go through and fix the display of that and make some general improvements to the generator. And of it like just to make it a little bit more usable, maybe extendable outside everything so we're trying to get together to be able to start like figuring out when to work on the project even though I know that he's already set up an environment has like been able to make some improvements so that's a big plus is just more like figuring out when we want to have meetings, and also have encouraged him to come to some of these the doxics meetings. Either one that he can make just to kind of see what's happening or like to be able to share progress, and then maybe especially like help get reviews, especially for the first part of the project is going to be figuring out what it should be like and we'd really appreciate some like documentation reviews to make sure it's readable, like it looks in a good format just so we start going down like, you know, coding the right thing. Don't really want to create like all this work and have this documentation generated and like, Oh, that doesn't make any sense or Oh, you know so like, we should have that type of improvement so it'd be helpful for the type of feedback. We're using the documentation getter channel to talk about the project so again if you have anything that you'd like to share or on the project you can watch it happen on the getter and everything should be good. Thank you. So let me embed a link to that one there. There. Okay, excellent. Thanks. Okay, any questions for Kristen on Google summer of code pipeline step stock generate. Next topic then June LTS change log upgrade and block guide and blog posts so Kevin Martins submitted the LTS change log. And there are some pending additional changes to it. Based on feedback. So that's good. There is an upcoming blog post to guide users that may be affected by the icon change. So what's changed is gift and PNG images have been dropped replaced by SVG images. So that means plugins need to adapt their usage so that they don't refer to these long gone plugins there's a worksheet of the plugins that are affected and pull requests for many of them, etc. So, any questions there. So, why did they replace Jeff and PNG images, is it due to some space constraint. No actually it was so that they could switch the switch the the icons to be themeable. So what that means is if I'm running dark theme. The icons don't disappear, meaning black regions on the edges of icons don't stay black when you're in dark theme actually switch color. So it gives them a facility to do the theming. It makes them higher resolution. And so they look better, etc. It also was a good chance to modernize. Okay. Yes, make sense. So, is it. So what are the next steps for the plugin maintainer is there any or everything will be taken care of. So there are absolutely next steps for plugin maintainers of the affected plugins need to need to update and release their plugin. And there's a list in a worksheet that notes the affected plugins and the most popular plugins have already been updated, or have pull request pending. So the challenge is what what we would affectionately call the long tail, the many plugins that have relatively small installation counts that may be important for someone even if it's a small installation count. Yes. I asked this question because this something which might also be helpful for my project as well. That's why I wanted to know. Okay. Yeah, good. Well, and certainly this is, if a plugin has not released in multiple years. That's that's a that's a sort of a negative indicator of health. Right. It's most plugins need to release more frequently than that. Just to remain healthy. Any other questions on the June LTS change log and upgrade guide. Okay, next topic then is the required Java 11 epic. This one is a nice example of effective use of Jira what we see here is the issues the tickets that have been the issues in Jira that have been identified related to Java 11, and we're seeing progress on them as we go forward so we've got some presentation tasks here. This one, packaging updates, and this one that Kevin Martins is handling an upgrade guide that Basel Crow is handling. Oh, I need to assign this to Kevin actually. So, so we've got, we're seeing good progress there and it's coming. So, now the just so everyone's aware of the, the schedule date is June 21. We'll switch to only support Java 11 and not Java eight. So we are less than a month away. Now the long term support release won't change until September. So, that's the June 21. We'll switch to Java 11. And then September. We'll switch to Java 11 and LTS. Any questions there. I guess in a related note Java 17 is looking really good. Likely, fully supported within a few weeks. The work on Java 11 has has exposed a number of interesting Java 11 related issues that we found are fixed in Java 17 and we need a backboard of the Java 17 fix into Java 11 to resolve it. So it's, it's cool. Meg, did you have a question. No, no, I just I was sitting here saying nice things and I realized you weren't hearing. Okay, all right. So we've got, we've got good progress there really quite pleased with how the Java 11 work is proceeding. There are still some surprises that are happening. And we continue to continued investigation of, of any issues that are reported related to Java 11. We had one that was really interesting for me anyway it was a meta space memory leak. And a workaround has been applied. It'll require a Java 11 Java 17 fix has been a backboarded to Java 11. But the earliest it can be actually available in Java 11 would be October of 2022. So the workaround will continue for at least that long. And there are other other issues like, I think we had a reconnect issue that had needed some work on it, and it's we're making progress there as well. Any questions on Java 11. Okay, next topic then she called Africa contribute on. So Saturday is the king is the wrap is the concluding meeting. The project is done. The reports are written. You can read them on read the reports on community dot Jenkins that I'll be pull requests have been submitted. Many pull requests have been merged. And some reviews still pending two or three. Now we still need Mark owes a blog post and a brief video embedded in the blog post, highlighting the results and the experience. Any question there. Yes. So, I was about to ask you what this blog post from your side as well because I'm also interested to know how was your experience of this program. Oh, oh yeah so so in my case, I found it, it was a little more stressful this year than it had been in previous years, because we didn't have as many people helping with it. But it was the projects themselves were more successful I think than last year, because we chose simpler projects, two of the three projects were quite straightforward. And that was very important because these brand new contributors have to overcome all sorts of hurdles as they are preparing to contribute their contribution can be blocked by things that are for long time users. Not a problem but for a brand new user. Hey I've got to get get installed I have to install Jenkins I have to understand what a pipeline is I have to start at running and deal with it on my computer I've got to download and install Java. All sorts of things that any one of them could be a barrier. And, and so the choosing simpler projects was a good thing. Did that answer your question dirage. Yes, it did. And also I read in the two reports of the participants and under the section of any room for improvement. I think I noticed that both of them suggested that onboarding should be like more easier for them. So what do you think about that, is it like something that can be improved, or is it just something due to the fact that they were new. No, no, I think, I think it is very much something that can be improved the the on so good observation key key points to improve better onboarding experience for the new contributors. We've got detailed instructions we had detailed instructions for them, but did not emphasize strongly enough that they need to follow the detailed instructions and do exactly what is stated there, and prove that they did, whereas last year what we did was we, we were quite rigorous you must do step a and you must show us a picture you must do step B and show us a picture. You must do step C and chose a picture and that rigor. We stepped away from it this year because we didn't have as many mentors by stepping away from that rigor I think we, they miss that had they done those rigorous steps they would have been much more likely to succeed on their onboarding. Exactly. I think I saw the onboarding guide and the instructions previously and I found them like they're very well written. So I was curious about like what was the problem. So now it makes sense because we've, we didn't ask them like each step, what's the progress so that's why maybe they jumbled up and maybe lost in between. Well and and the, the step by step guides had some flaws in them as well right because I created three separate documents, and the step by step guides in each document was not tuned to that specific onboarding. They were mostly a copy of a base, a base thing and, and that meant they would reach a point where hey, this says something that I can't imagine how it's relevant to my project. Oh, okay. So it just, it's, it's one of those where we may want to do something like may may want to do a do an online lab or something like that. Did they work natively or did they use get pod. I don't think any of them actually used get pod. So good question. But in, in this case, most of them were not operating in an area where get pod would be crucial. And it's the, the point there is native work because screenshot updates just requires that you run Jenkins. And then you can, you can actually submit either using get, or you can use GitHub's web user interface and create your pull request there. So no, no local development. Yeah. Likewise, the inclusive naming. When, when they made the changes correctly. They did not require a recompile, because what they were doing was looking for places where they could make safe textual substitutions, and we had told them where they were safe now pipeline pipeline steps. They definitely are pipeline help they definitely did have to recompile, but in that case the two people who were assigned were both developers who'd been doing development work already professionally for a year or two. And that was done on local computers for them. Because I was saying, of course, I wasn't, but that you did do more like the onboarding you had before you actually put them to work you had some onboarding sessions with them this year right which we did. We did we spent two weeks of, of onboarding. Yeah, and in those two weeks. We did to Wells for instance we, we gave them a tutorial on gets and GitHub and the GitHub command line, and they was very well received and they were, all of them were universally grateful for those, those tutorials to get them started. I think they're correct in observing that there's still more to improve and getting started. Yeah. All right, anything else on she called Africa. Okay, so remaining actions are blog post video embedded in the blog post. See now I've asked for that, and then I'll attend the Saturday concluding session. So before we, for me, outdated pull request is a good thing I would propose we move these other two ahead of it, just to be sure that we get them done. So one of the things that we observed in Europe office hours today Veehan was there but Kristen had work meetings, would those of you who are attending this meeting be available if we were to shift the meeting one hour later. This one. Yeah, this meeting yeah. Would that work for you Kristen or no. Yeah. Wouldn't for me I've got dog school dinner. You say it would not work for you make right. Yeah. Okay, so if well so Meg with dog school if we shifted 30 minutes later. That would give you at least the first 30 minutes to be with us or do you end up needing to leave at the half past leaving a little bit early because I have to go down and I have to base would be at the restaurant by like 810. Okay, all right so then time shift may not work. I just tried like, getting to that meeting more of a just today was there was a lot going on. And I'm like support person like this, the support rotor this sprint so like any questions coming in about any of our stuff it's like all hitting me. So it's like, oh man, I had a lot. So a lot going on I was really upset I couldn't be there but and not a problem Kristen we've got it covered no no problem at all. We've got it covered and you can always certainly always schedule separately behind at some other time. Yeah, we're trying to get that together. I was hoping that hoping I could really good at this meeting it's like just didn't pin out today with stuff that happened on our team. But yeah so we're trying to meet separate like at a different time to but I did honestly want to encourage like come into Docs hours and I did say to him it's like just even if you don't have to say anything you don't you don't feel forced to share anything just you can just come and listen, but hopefully, you know, when we get to the point where we coding period starts and stuff we will have stuff to share. So, but just attending and listening as a fly on the wall. I'll try to get there. Be here than Meg. Great. Okay. Now, then on to the next time topic. I'm out of the office next week goofing off in Pittsburgh my son has promised to take me to see his Jenkins installation where he, where he controls the builds of robot software. And we're going to go play in an Eastern US. I don't know if any of the rest of you have access to the zoom account so I'm prone to say let's just cancel the meeting. Any objections to canceling. No, I'll have company actually works nicely for me. Okay so make I'm having difficulty hearing you but you're okay with that. Good with that yes. Okay, great. Okay. Dear Raj Kristen are you okay for cancel meeting for next week. Sure. All right, great. Last topic then outdated poll requests. So, about 10 minutes so but we can do something. Every little bit helps right. Well, look what we've done so far. A week or two ago, the oldest poll request in the queue was September of 2019. And now we've moved it up so it's November of 2019 so we're two months newer. And this one is one I have to work on so I it's this is the internationalization one. Okay, so are you ready to to do some some more reviewing. Sure. Okay, so actually let's let's take this one I'm not sure that vocabulary updates. This one was put on hold, because job and project. Yeah, we didn't have the agreement in the community right. Well and I think we still don't right so what we have is in Sega interoper in the interoperability SIG. And it's the word job to describe what the Jenkins project calls right at the moment project. But the barrier there was Tyler for instance felt like really and and others who know the Jenkins object model say look it's not a project, or it's not a it's not a job job is a very specific thing in a in the Jenkins object model. And for me as a user, I'm less concerned about the object model and more concerned that when I refer to the thing that's running. I call it a job, or I call it a build is running and the thing that defines it is a job. Yeah. So maybe I guess I'm now I argued myself into the position we leave this one open. Well. It was really open I mean, I'm almost wondering if it was there an associated issue with this in the first place. There there was it came from. So it came from fix the terminology in the glossary this issue report or no it came from this. Yeah, here we go. CDF interoperability SIG made this change to use the words. And now as declared, hey, project is synonymous with job. And then goes through other other descriptions and so job now fits that showing is merged. This right so this is the this is notice the destination CDF foundations interoperability SIG. So right now they the CDF interoperability SIG is inconsistent with the Jenkins glossary. The Jenkins glossary proposes here to say, hey, let's change this to match so that we use job to describe the definition of the thing build describes the the single execution of it, etc. I mean, I'm almost wondering if the glossary should reflect that there are different camps on this. Oh, and it does have things that are deprecated terms in it. Right. Right. So, for instance, today it's job says a deprecated term project let's find project it will now say a deprecated terms synonymous job so they both exist. And they're both in the glossary it's just which is the preferred term in which is not. And that's what I'm saying could we put a note in that said, you know, SIG operability defines this as such and such. And some members of the Jenkins community do not agree with us or something like that. So, see, for me, I think, I think we should just accept that this one is going to be the definition. Let's just admit we're going to use the word job and I'm, I'm going to disagree with Tyler Croy and say that if he wants. If he wants to push he needs to come back and help us. Because the more I look at this the more I think we should just admit we're going to use the word job to describe. So Kristen checking with you you've got more of a developer hat than I do. Okay, yeah. Well, he hasn't been here for a while too. Yeah, I was kind of like, I was involved with the project as it was previously so if this is kind of the direction we're going. Like, I think I can see job as a little bit more like you run a job. I think, for me, for me, this change is the right change I think this change makes sense. Now I think there may be another one like it. Let me see if there's, there's another one here that's also related to the glossary. I thought there were two of them. Nope, I don't see it. Vocabulary is there that's the one we're reading. I thought there was one from Runcia yay. Oh, apparently not. I don't see it. Okay, so back to the question to all of you. Would you be okay with the idea that we accept this one and we're going to merge it. I think so. I still and I wonder about calling it deprecated or I don't know when there's when there's a mess in terminology I kind of like if the glossary. I do it everywhere if the glossary reflects that so if I look that up I don't know the history I know there are, you know, that there are warring camps here and okay now I'm not I'm not sure I'm not sure I'm clear Meg on your concern there could you say that again. I guess what I'm what I would love but you know it's just me is to give the definition that match is the operability sake. I think that this is done to match the operability sake, and some members of the Jenkins community prefer the other or something, and just noted I don't know and maybe that's too messy maybe that's a historian me that just wants to keep all the history everywhere. I mean that that that okay I admit that does that feels to me like that is messier than I want it to be, but but keep keep going persuade help me understand so the idea then is that it's important for people to understand that. Because I'm in a discussion and some people are talking about a job and some are talking about a project and I want to know what the difference is. And I've got partisans of the opposite way, it can choose, you know, so then do I stand up to one really I'm a junior person I stand up and say no no that's the wrong meaning of job. According to glossary and maybe that's what we want I mean, I don't know but I. I mean a lot of places and that I've had to write docs that say some people say you should do this way and some people say you should do it that way I sometimes even given arguments for it that. So that then you know the difference between this is true we all agree on what this is, and we don't agree on that. But that's just me it may mess other people up more. See, I'm on the, on the other people side on this one so dirage and Kristen open to your comments. I think I do not have a strong opinion on this because it's quite technical so I'm not say much. Okay. And Kristen, I know I almost there is like I feel like we're reading into like a pipeline workflow but with like, not as high stakes but like, because we're not renapping like essential Jenkins components but. I. And then we merge it if somebody on the other part of time can always open a new one to challenge it. I love that like a combative or less. I think part of it is people might not even really notice it's more like. I know that we've gone over the whole what is the cold fuel use of this versus like what is the coding use for the different pieces and it. I almost want to argue like we should use the colloquial version, because that's how people are going to reference it. And I think that matches with my thought and I know in terms of the colloquial use in terms of the conversational use. Yes, I use the word job. I use the word job very because project for me has a different meaning, it means something has a defined start a defined end and I'm rather rigorous about the use of that word so I naturally misuse in in the old context and called as a job. Yeah, that's Tim Jacome had the same observation for me just always calls it a job. Yeah, I think even if we go into the getter or in the other thing everyone, you can calls it jobs, right, builds like build for a single run of a job is like like that exact definition. Exactly. Yeah, as a result of a single job execution of a job. Right, and you just, we described it very fluidly and I think having the glossary say something different is is not not helping people. I imagine if someone came to ask a question and they had gone to the glossary first and then they asked the question using the terms of the glossary, would people be able to understand what they're talking about. Right. It's like, even if project is technically what it's called in the code, sometimes things change I mean workflows, as we say workflows still all through the plug in, even though we call it a pipeline. I think that it might be, even though it's called a project in the code, it's referred to as a job like and. Right. Okay, cancel. I'm going to have to go read this one more because there's some plural, plural misuses and plurals here that I need to understand. Is it, oh it's pipelines. So it's the second half here that needs to be and then in that case it should not be capitalized it's plural lowercase got it. How did I make that mistake comma. Oh, no comma. Seriously marks typing is defective. And not uppercase. And not a proper noun. Okay, got it. And back to regular screen. Check those and then merge it. Yeah. I think this is going to continue to be a mess. And I don't think we can't and fixing the glossary or not fixing with grocery change that so. Yeah, yeah. But it's kind of people are just going to use with the, what they're used to using. And people have been, and you know, in the founding years of Jenkins, careless with terminology. Exactly. Yeah, so. So we'll embrace and we'll love it it'll be okay. Right. Okay. So in general, it sounds like so Meg, I think you've come to be persuaded that you'd be okay if we merge this. Oh yeah, I, I was all yeah. Okay, good. Then I'm going to schedule it to be merged when the. I think the alternative is to close it and go back to the original issue and make that point to this PR and said we could not get community agreement on it. And so we closed it and if you really care you can open it up. And merge it. Yeah, so let's do it and start it all over again if they want to. Let's let's go with this one then and we let it merge now we have officially run out of time Meg for you to be able to to make your appointment. Yes, is there anything else we we are now below the 30 open pull request threshold. We still got 30 open we just closed. Oh no it hasn't closed yet we will be below 30 within the next 30 minutes. And we know the one is the automated change logs so that's a big plus. We've seen the change log ones. Right so yeah, we've got two chain two change logs and this suspensions. This one is sort of mechanical and dependent on something downstream of it or upstream of it. But at least being and we know that that has a definite date so great. Absolutely. Yep, we're making progress. Anything else we should review while we're here today. Now. Okay, let's call our session done. I'll stop the recording. Thanks everybody. Thank you.