 Welcome. This is Docs Office Hours. It's the 20th of June, 20th of May, 2022. This is Asia Office Hours. Thanks for joining. Top topics I had are disabling the Docs mailing list. Switch to community.jankins.io. This is a topic from governance, localization. Localization and internationalization progress report, something we discussed in Europe Office Hours, 12 or so hours ago. June LTS change log, the required Java 11 Epic and its timeline. Sheikot Africa contributon and then outdated pull requests. If you will be pleased to note last meeting, we closed some outdated pull requests on jankins.io. Not many, but we closed a few. Any other topics you want to put on the agenda. Okay, then let's go ahead. So this next this one, the first one is one that needs some some quick conversation so we use. This is a mailing list on Google groups, and it's a very infrequent to use mailing list for docs. I suspect most people do not read it. As an example, we had a post from Basil Crow. The preceding post was four days ago, so it's maybe on average, one post a month, maybe two posts a month is all and not a lot of response to it most posts have no response whatsoever. So given that we're not getting responses there, and it sort of fractures where we're communicating the proposal is let's move or move let's switch and use community at jankins.io and put things under the sick docs category or sick docs label. Like these items are. What we do is declare the docs mailing list, still available as content but switch it to read only so it would not accept new posts, I may put I would put one email message there which says this, this mailing list has stopped, and it's being pointed to this tag in in jankins.io. So Meg and Kristen would you be okay with that I assume that for you this mailing list is not a crucial source of information, etc. Yeah I'm cool with that I'm yeah really looked at the mailing list. Right. And that's that's most of us truthfully. I pay more attention to either, like, definitely get her first, and then the, then the community jankins.io just because, at least with the getter I can usually if I'm have my tabs open I can see if there's a notification so it's a little bit easier sometimes to me to do it, then, you know, clicking into the community jankins.io so having reducing the number of places where we set the easier for everyone I think. Okay, so, so that that works well for me that gives gives me a chance. Meg are you okay with the idea then as well we'll we'll plan to shut down jankins documentation as a mailing list, and direct people towards posts there on community jankins.io. And I'm going to assume silence means yes Meg. I'm muted noted means I coughed and muted and didn't unmute yes, it was it was I agree totally that makes total sense. Great. All right. And we had we I missed having the having the conversation during Europe office office hours but I'd had the conversation with the governing board. It was prior and it had several of the attendees Bruno and Basel were already in attendance at the governance board so I think we've got, we've got more than enough people agreed that we'll do that. Good. Anything else on the docs mailing list topic. Okay, so next topic is localization internationalization the crowd in project that we've started crowd in jankins.io now has eight plugins on it. So, and we've got French localizations. Submitted by Bruno for all eight and easy and pull requests submitted for those localization so really positive. Now what we've got upcoming is Mark and Darren will host a live stream will do a live stream live stream on internationalizing Jenkins plugins. This will be the sixth in the, what do we call it modernizing a Jenkins plugin video series. And this will be then be will be embedded eventually on www.jankins.io. Any questions or concerns there. Now one of the one of the topics that we noted in in the Europe office hours today was, we've got a challenge here that we would really like it if we could use language translation as a hacktoberfest contribution. It's cool it worked very nicely last year when Duchess France, a group of women open source contributors in France contributed several localization improvements, however, the system submits the pull requests as a bot, rather than submitting them as the person who did the translation or the proofreading. And so, I've got to check with our leader there Alex Brandis to see if there's some way to switch that for the period of hacktoberfest so that the pull requests are submitted by the by the translator. As though they were the transfer I'm not sure it's possible because it may require credentials that crowd and actually does not have. I think the previous one. What exactly do you mean by embedding this in in Jenkins IO. The instructor, the video and the instructions I'm sorry. Oh yeah good good question so what I mean is something like this. Let's show an example so on Jenkins.io we have a number of places where something is described. We found that Darren had created a video, and we use Darren's video by placing it on the page like this. Okay, um, where I don't know where is that you were doing massive work on pipeline development documentation at one point what is the status of that. Yeah, so that that pull request is stale right now. It still exists as a pull request but it's still draft and not really ready, not ready to merge because I've, I've not made and not had time to make progress on it it's this pull request right here number 4806. There is a number of videos embedded in it and you see a whole bunch of comments there on what with Jesse Glick saying wow this is a lot only to have some time to go over it. Yeah, do we, is there a section on internationalization is my question. Not yet, there will be. Well I don't know is that going to be another thing that we have to, it's going to make it even harder to be able to get a review. Well, it doesn't have to go into this section, ultimately, we can, we can, we can declare this thing done right now. I'm not ready to say this is done because the development work that I want to do is not done. Okay, and I've actually got authority to all after I suspect I'll have to do is tell, tell Gavin mogen here Hawkeye. Give me an approval. He says yes and I'll merge it. Okay, the problem is it's not ready because I'm not ready to have it have it reviewed yet I don't mind if Jesse if Jesse finds problems with it later we'll just fix them. Yeah, that's yeah that's true I was like oh no I didn't want to turn it into oh I just reviewed everything now I got a review. No, no, no. That's definitely not not the case. Everybody even if there's pieces or, I mean, the old the existing docs it has how so many really important sections that just say this needs to be written up. Yes. And why you know the stuff that isn't ready or even say this has not been reviewed, or this work in progress or construction and and we don't even have to do those this this material I'm perfectly comfortable saying hey, I tested it, it's not a work in progress. Yeah, in the sense that I've checked that these steps work for me. And if someone else finds a problem they can report a bug. So now we do have instructions right now on how to do internationalization so we've got instructions that tell you how to internationalize Java source code and jelly views and groovy views. However, I disagree with or find them in find found them inadequate personally, because they use a technique that is not conducive to crowd in. Okay, and I think it's much better. If we teach people, if you'll do this, your life is easier as a Java developer. And our life is easier because translators life is easier because they get to use crowd in instead of having to create a handcraft, all the property files themselves. Right. What is going to happen. Long term once, let's say we get everything internationalized what we do but let's say something has been internationalized, and then there's significant updates to it. So it's easy to go in and just internationalize the new parts or review everything and do that or. Yeah, I think I think it isn't localized or I think the crowd and has a facility that will tell you that an upstream and original string will change, and it will then invalidate the downstream translation I haven't tested it but it's a good question let me make a note to myself to be sure that we test that workflow because I'm pretty sure we've had an exact example of that. And we forget, there's a future here. Right good idea so that the that crowd in, certainly the current tooling without crowd in, make it very very difficult to detect that problem detects changes in the base string, and invalidates the, or requests, a new translation of the revised passage. I used to work with this fellow I really like to really respected him and he was really big on having tests for everything. Is there any possibility of pulling, making crowd in part of the CI process. When one merges something that it would flag up and say hey there's stuff here that hasn't been localized. That would be really helpful already happens. So, so let's let's well maybe what I can show you is let's look at at a plugin that has is now part of crowd in. So here's this crowd in this crowd in enabled plug in elastic axis. Okay, and what happened was when new strings arrived when new strings became visible. They were made visible in crowd in, and then crowd in receive translation proposal from in this case from Alex Brandes in German. He proposed hey, here's the translation. And when you say crowd in, did crowd in on its own without Alex saying hey, would you check this. On its own just popped up and said hey, it did that's correct so every every 12 hours crowd in checks for new changes in GitHub. Oh, so it's, it looks like this. Here we go what we'll bring it up and get to look at it so for me here are these here are these projects, and the plug plug in we were just looking at it on Jenkins is this elastic axis plugin. And so it says hey, it's been translated to Chinese simplified Chinese traditional French, and a portion of the German and some of the Italian so I don't know if I don't know. So yes, that was me who did the Italian know it's not really good Italian. So, so this gives hints and so you see who's involved so this is Alex that's Bruno. This is Chris Stern in in Hong Kong. Very nice. Yeah, it's actually quite a quite a comfortable user interface now. Now it's, it's still, we would love many many more. We're still in the early adoption phase. But for instance, put Jenkins core on there yet we think there is much more work that we can do in plugins to become comfortable with it familiar with it. Before we do something massive like Jenkins core, or even like the get plug in or the get client plug in that are high volume plugins we want to be sure that these lower volume somewhat safe plugins are easy to do, and work well before we go with big high volume plugins that are used frequently. Right. Did that answer your question. It did. And I'm so impressed. Yeah, so, so back to your thing on detecting changes in the base string. We just had an episode had a case in Jenkins core. Not crowded and able jet but in Jenkins core where a string, a translated string had been updated, but the translations had not been invalidated. And because of that local localized users receiving bad information. So the case was, we're announcing the end of Java eight support. We changed the date. The date to June 20 June 21. But the problem is the localized versions still said the old date. And, and so we corrected that by deleting the, by deleting the translations. Okay. So that they'll now show German or show English language again. And if you care the first item in this thing you left out string you had a translated had been updated. Oh translated string. Thank you. Thanks. Everybody's copy editor. That's great. Okay, so anything else on localization I hadn't actually intended to spend so much time on it. Okay, LTS changelog has been has been created by Kevin Martins. He and I paired up to do it. It needs needs review. And needs needs a blog post announcing the major major changes that are included in the June, June LTS. He's working on the blog post yeah. Anything else on that changelog. Nope. Okay, next is the required Java 11 epic. So, so beginning June 21 Jenkins will stop delivering a Java eight, a Java eight based Jenkins, we will switch to Java 11. And then in September. We will do the same change in the long term support release. We've got a bunch of a bunch of work described in the Jira epic. A bunch of work happening in, for instance, various sub projects of this thing, like the jacksby one that there are there are plenty of things that still work is going on. And we feel like it's, it's reaching the point where we've been running on Java 11 for, I think over two years. It's time now for us to switch off Java eight and be able to use Java 11 features natively. Wonderful. Yeah, any questions there makes me feel old I remember the hack, the hackathon where your guys were just starting to play with implementing Java 11. Yes, yeah, well and and there's, there's a that that transition fails about like this one does in terms of finding things that have changed, and making sure that we can safely make this transition for our users. So an awful lot of work going into making Java 11 work successfully. Yeah. All right. Nothing else on Java 11 she code Africa contribute on is now in the reporting phase. So that means three projects inclusive naming pipeline held and screenshot update. And so the, the seven women oh and project management. The seven women involved in the project will be posting their, their final reports to community dot Jenkins.io. And that will look like this. So if we look for she code Africa. What we see here is, for instance, this is from peace, okay for. And she posted introduction summary of the camp. Good story told problem she encountered and things she learned from the experience and what we should do better next time. And that's exactly what we were hoping for very nicely done and have, have suggested that the other new contributors do the same. That's really it for what I had there so sample. So in terms of which projects work well the screenshot update and the inclusive naming went quite well pipeline help was a struggle but the two contributors there have found some new things that they taught me. And, and have been contributing as well. So, like the fact that it's not just us teaching them they're rather helping us learn more things and see how to do things more effectively. That's fabulous. It is really pleased. Any other topics that we want to talk today, we've got outdated pull requests and we could spend the rest of our time together on on outdated pull requests. Okay, I have to leave in about 10 minutes but we can do 10 minutes and. Okay, guys can continue or get a 20 minute break. Well, and I'm fine if we if we say hey we're done I'm happy to look at, I think Kristen you and I had a really good experience the last time we did this, you want to try it again. Yeah, sure. Let's do it. Okay. So, this is truly group exercise trying to decode which of these long ago pull requests should remain open. Right. And so, last time we were able to successfully close. Okay, here's, here's, here's one that I cannot close because I'm actively working on it. Okay, there we go. Next one the next one up from June of 2020. Documentation firm environment when with comparator. This is conditioned on this this pull request being merged. And it, it hasn't been merged. And it has conflicts now so I think we could safely close this one. We're doing so was that soft was that we get software documentation for it. We have, we have a pull request that it's not been merged. And because it's not been merged and the pull request is now two years old. But is, is why is this not I want to know why this hasn't been merged me should it have been merged or is it. I think it's because the maintainers are not ready to review it. It's just a plugin feature request. And, and that's from 2019, it's even older. Right late, late 2019 this is Victor Martinez, who submitted it and, and I think it's a very reasonable thing but until this is until this thing is merged, there is no reason for us to leave that thing open. We're not going to propose we close it. It doesn't, it doesn't get lost. It's just closed. And if it were to be merged, it would be. Oh yes it's easy to find because he references the pull request in, in the software change. Pull request description so this thing is a link to the documentation and the software stays open right just exactly I don't have any authority to close that so. I'm closing this until can reopen when the, when the matching software pull request is merged. Fair enough. Sounds good. Okay. All right so we've made progress of one. Oh, another one from Victor. All right so, and this one I suspect has the same. I was wondering the same as like I bet this is something similar. It is the same condition right so let's follow the same pattern closing. For now, once reopen reopen once the matching software change is implemented. Let's just be sure that it doesn't damage this pull request yet show it change the color of the icon but that's all. Okay, right now. We've got changes requested on this one and this one that have had no action the action would then be someone else has to adopt them. Pick them up make the requested changes and then apply them and likewise for this one this one this one. So then we've got a vocabulary update proposed here that's been put on hold and another vocabulary update proposed will put on hold. Oh the job and project one. Oh God. Exactly. Oh, that is oil and water religious. Precisely that that is, it was like a pipeline and a workflow right there right. Actually it's it's I think even more contentious than pipe. Remember that. It's the. I don't know. Yeah. Community. I get the feeling that the community, except for the writers is very comfortable with the fact that we misuse that we have all this terminology that we use different ways and different times and so what what there are, I would phrase it is that there are, there are people who are very precise in their phrasing and their precision in phrasing is related to the, to the Jenkins object model. And then there are people who are precise in their phrasing, and it's their precision in phrasing is in disagreement with those who are precise with the Jenkins object model because they're precise in their phrasing. In terms of the way users use the words. That's, that's been my discussion with Tim Giacomo on this one anyway is job and project. Those have very, very precise meanings in the Jenkins object model, and one of them is a better choice than the other and yet users use the word job. They do, whether we like it or not, and they don't care what the inheritance tree is in the, in the Jenkins source code they use the word job to describe it. And when talking about it always was with it was that all of this was set in concrete before they came up with pipelines. Again, same, same thing that they're pipeline they still call it a job. Right. Yeah, go but then when I get into something like the security matrix, when it talks about jobs. I think some of that only applies to freestyle and some of it applies to pipelines and it's. It's very, very, but yeah there's, you know, yeah well but but wouldn't that disambiguate with a pipeline job and a freestyle job. And isn't isn't that a way that we could terminology wise disambiguate by saying, well, I go into that course because we never really documented those different things very well anyhow. But that they should have been split up that you know this applies to both pipelines and freestyle and this only applies to freestyle and this, you know or something like that. We don't go back and get other pieces like that. And I feel a lot of sympathy towards the people who are using it from the context of what the user says because that's kind of, most people are not going into the deep bowels of Jenkins to understand the inheritance. So, it's very hard. Now, I just realized we've got Meg for maybe two or three more minutes and I think there is one candidate here that we may be able to close, and it would be one that fits with Meg very well. Meg converted the agent to master access control to GitHub is a, I believe now dead. Right, because there isn't really anything about agent to master control from the wiki that is relevant. That's wiki data right agent to master access control. As far as I know anyway is, there's no switch anymore right there is just no switch. Not even off the first I thought it was just on the gooey but you can't turn that off. Right, it's this always on. Some people can figure out how to turn it off but we're never going to document it. Right. Well, and yeah it's not intended to be switched off as far as I know. Right. You, if you choose to turn it off you're disabling a major security feature. Yes. So I propose we close this one because agent to master access control is really always on now. Who is Larry soul and where is he. He's in Nigeria. Okay, and was he attempted to contribute this conversion. Back in 2020. So it was June of 2020, I think, as part of the UI UX hack fest that we did. Mayor, yeah it was May of 2020 so it's now be heard two years ago. You won't know. Looks like a candidate can no longer be disabled. Yes, exactly is is cannot be disabled from the UI. I have no idea if there's a property escape hatch but good. Okay. We have now successfully closed three and Meg let's call ourselves done, because that way we've we've hit your times timeline. Kristen, thank you very much as well. Yes, I have three. That's a really good number of you're forgetting those numbers down. And we're down to only 33 open and several of these are screenshot updates that may merge pretty quickly. So we, we might get down to not we won't be down to one page but we're getting much closer. Cool. So what are the public announcements. Are those going to be on Jenkins scuzzy tomorrow. They, they after Google makes them and makes the announcement publicly, then, Jane, www.jankins.io will get a blog post, etc that says more details yeah. Okay, just curious. Great. Yeah, check, check Jenkins.io for the announcement tomorrow. Hey guys have a great week. I feel bad I'm not doing anything with this meeting but I look forward to seeing you guys every week. Well it's great. Great to see you and thanks for your help with closing pull requests and reviewing them. Thanks. Take care. Thanks by all.