 Welcome, this is the 27th of April. It's the Jenkins user experience special interest group reminder that we abide by the Jenkins vote of conduct. Be nice to each other. Topics that I've got on today's agenda, preparing for the June long-term support release, possibly other UI improvements. And if Jan, Evian or Tim join us, UI improvements topic. Alex, to you, I guess a question would be, should we put localization as a possible topic here? Is that something that actually fit into UI UX meetings? I don't know, it's a good question. I mean, at some level, it certainly fits as part of the user experience because presenting to a user in native language is a much better experience than presenting in a language that's non-native. So maybe we optionally have it at the end if you're okay with it. And we talk about it here just to briefly highlight it. Would you be okay with that? Yeah, for sure. Okay, great. Any other topics that need to be on the list? Okay, then let's address the topics we've got. So LTS baseline selection, our usual schedule would have been, the schedule would have selected last Wednesday, the 20th, that would be the 20th. And hasn't been selected. Tim started an email thread, proposing a selection to choose 2.344 or 2.345. And I would, so Mark's question was, can we wait one more week? That would be then a two-week delay because there are a few things that were of concern for me in terms of open bugs. This is a good place where I'm open to others. I believe Alex, you asked a similar question that led that conversation. Any insights you want to give Alex in terms of your experience with most recent weeklies? I think the recommendation was 2.344, that actually contains quite a few regression releases from past weeklies and actually from past LTS lines. We see back to 2.3 and at least I think 2.89 or something, at least very, very old in terms of LTS. And 2.345 contains at least two or three regressions, but these were minor ones under your X regression dashboard. Actually, that's a good one. Maybe I should bring up the regression dashboard here because that's a place where this group should probably look to see are there things that worry you as you look at this list. So here's the, this is an opportunity for us all to take a moment, look at these descriptions and see if there were a few in the mail message that I highlighted. For instance, this one right here worried me, broken sidebar icons just because it was a little surprised. This one is ongoing effort in multiple places, right? Alex, that's a, there are several plugins that still need work to be ready to adapt to the SVG icon removal or SVG icon removal and replacement with better icons. Yeah, I have started Google spreadsheet and drop the link in the SU. Oh, good, okay, so this one has a link to the sheet right there, excellent. Okay, excellent. Oh, very good. Okay, so list of plugins with unreleased changes and unmerged changes and some of them highlighting, okay, there hasn't been a release of this thing since there was no real activity since 2012, yeah, okay. Dead plugins or abandoned, good, okay. Yeah, there are quite a lot of plugins which are, I would say abandoned because they had no SCM activity for at least five years on the D4 branch. That's why they are listed on a separate sheet. And everyone else is pretty much working in the progress already to be released. Okay, and so these look very promising then, okay, so merged and released, this says 47 of them or 46 of them have already been updated. And then we've got another set of eight that it's been merged just waiting for a plugin release and another 28 that it's not yet been merged but the PR has been proposed, good. Now this tab, the one with marked for deprecation, my assumption here is just as we did for the tables to divs, if something's deprecated, we're not going to attempt to bring it back because for example, we would have to fix a security vulnerability before it would be distributed again. It just doesn't make sense for us to say, oh, we must have a fix for something that's already vulnerable. Yeah, okay, excellent. Alex, thanks for doing this. This looks any questions from others or concerns on the icon improvement project. Okay, any others in this list that others may be concerned about? Let's see the one that I was concerned about was in Google groups. Let me go find the message. I have to see the list next LTS baseline. Yeah, so broken sidebar icons. Oh, right, this one that I've had multiple requests for and I've seen no activity here. So I think this one may be one that it's this topmost one. The, when a build is queued but not yet started, the new icons give no indication of that whereas the old ones did. And I've had at least two different cases where people said, hey, I like this. I need that. Can we have it back? Now, Alex, in your experience, is that feasible with the current technology, with the current stack or is that something we're gonna have to have a different icon or something else? If I remember, if I understood the issue correctly, I think it's about the computer icon no longer blinking if a computer's launching or something. Sort of close. It's that the arrow that shows that to start a job or not used to blink when it was in queued but not yet started. So it was the job itself would blink. Not the computer icon but rather the here. It's easiest if I show it in Jenkins. Is everybody okay if I just bring up a Jenkins to show it? This icon, right? Let's look at this one here. So the icon over here used to blink. Oh, yeah. I think that used to be clock and clock to underscore animator tip or something. Right. Yeah. So to me, a technical question is, is there a way to allow us to have this highlight that something has queued but not started? I guess likely. I mean, the logic existed before and we didn't get rid of it. We just got a rid of the icon so we could likely spin up another icon for it. Oh, good. Okay. All right. So I don't need to be concerned that there's a technical limitation. It's now a coding thing. Excellent. Thank you. Okay, good. Back to the team. Are there other things on this list that are of a concern for you? I mean, I like that this is sorted by create date because anything prior to about March, about this row that I'm highlighting is old enough for me to not consider it really a risk to the June release, right? Okay, they are regressions. They are things that people have noted but not a concern given how old they are. We've lived with them for a nice long time. All right. Then I think, so to this group, are you okay with the idea that we continue asking and trying to persuade Tim that let's wait for either we take three, four, five or one more and we may still have some backports or we wait another week and take three, four, six, the one that will be next Tuesday and then proceed from there. Any concerns or objections to that idea, Vadek? You okay with that? No problem for my part. There is nothing related to security with the next year. All right, great. Okay. Anything else on the preparing for June LTS topic? Okay. Next topic then was other UI improvements and I think we had discussed this in depth the last time, Vadek. Anything, I assume nothing's really changed there since then? It's okay, nothing changed. Okay, so no real topic since last session. All right, and since we don't have Yan and Tim here today, I'm not gonna, oh well, I guess we've got the new login screen that we could show. Yeah, let's do at least a demonstration of something that has arrived. We have this place where we've got it. Let's see if it's up to date. Weekly.ci, I know you're not using it nearly enough so you should be reminded that weekly.ci.jankins.io is here. Oh, except it's got an, okay, login to Jenkins. Am I running the wrong version? Oh yes, it's one, it hasn't updated yet, sorry. So I'll have to, after our conversation, if you want to see the new login page, I can bring it up. This one is still not updated to 2.345. So we just got a new login page with a slightly different layout. Next topic then, localization and crowd-in enterprise. Alex, you okay if I bring up crowd-in.jankins.io to highlight it and let you talk for a little bit? Yeah, for sure. Okay, so thanks to the infra team. We have this site now and I've got to make it big enough to read. Is that readable? How about that size? There we go. Okay, Alex, your topic. Yeah, crowd-in enterprise, that is basically, I think one of the major topics we spent the last five hours on. And it's basically, I mean, crowd-in is basically a more streamlined solution to work with translations, especially with and by people for not necessarily familiar with Git-based environments. Yeah, and this is our Jenkins instance, crowd-in.jankins.io is sponsored by the crowd-in team and hosted by them. And we just have a senior record for it to have it under our domain. So for me, the brilliance of this solution, so Alex, are you okay if I highlight some of the things that I think are really, really exciting about this? And so I was just discussing with a French native speaker a few minutes ago and his first experience in trying to contribute to Jenkins had been attempting to do some Jenkins translation into French and using Java property files and various edits and how to find those things. It was really complicated and a complete failure. Whereas here, when I want to contribute a translation, so okay, this is what we envision is that each plug-in and Jenkins core will eventually be in this list of open projects and someone who wants to contribute clicks one. And then they click things like, I want to work on Italian and here are some messages that have been translated. Here are some that still need to be translated and I can very easily navigate through these. Let's do one. And they let me, they offer suggestions for translations. They offer, and I don't know which of these actually to take, I think I want this one to stay in English. So, but this lets me do translations. And now that translation is now ready. It's been submitted, now I can switch and other people would take this role then of proofreading my proposed change. And after they've proofread it and said, yes, this was accepted, then a pull request is submitted to the plug-in. And that pull request comes through my usual development process. So all I did as a native speaker was interact with this webpage that gives me great suggestions. And I get to submit proposed improvements to the Jenkins translations. Alex, back to you now. I'm so delighted by this experience. I just can't express how much I've enjoyed this thanks to Alex's work. Yeah, at some point on background information, like Marc said, proofreading actually equals the role of a PR reviewer on GitHub. So basically nothing specific about this role here. Basically like any other maintainer or translator who is familiar with the language can approve these strings. And once they are approved, they end up as PR on a separate branch on your project on GitHub. Which you can actually just merge right away because you have approved these strings on crowd in beforehand. And for me, the concept of a proofreader lets us also admit that there are times when the person who's finally merging would benefit by having a native language speaker who does the proofreading instead of me doing the proofreading as the maintainer. So Vadek, with your comfort, let's see Vadek, I forget, is your native language French or German or? It's French. Sorry, sorry. Switzerland is a complicated country, right? There are only four native languages in that country, right? Yeah, exactly. So the French translation process then becomes much better because it's a UI focused on doing translations. I'm so pleased with this. And Alex, thank you so much for launching it. We will do a, Alex and I will do an online meetup within the next week or two to highlight how this works. But for me, it's been delightful going through it. It's especially interesting in some of your way when you don't have to care about all the encoding of the accent, especially in French, this kind of thing. It's just a pain to do the thing. And I don't even imagine the situation for people with Cyrillic alphabet. I have a Belarus people in my team. They try to do some translation and it was just naturally nice. Right, or here the Chinese simplifies or Chinese traditional, right? Where you've got a multi-byte character and this webpage is going to present in multi-byte, multi-byte suggestions, right? And it's just going to do it. So, oops, this one didn't offer me any. Oh, maybe not. I've never done Chinese before. So we'll have to see what they've got. But- I don't think you have to say that any Chinese plugin before hence our translation memories are pretty empty here. Right, that was what I wanted. Anything else you'd like to highlight, Alex, on the crowd-in integration? I don't think so. Probably doing that on the online media then. All right. That covered all the topics I had for today. Any new topics that have come up since we started? Just one point, Konstantin Krodin. What is the flow after the thinker approved? You are creating a pull request directly from the flow from the application. What is the process in a sense? And you mean like what happened after you have approved these trends on crowd-in? Yeah. The plugin mark just showed is currently set up with a GitHub integration through GitHub Actions and runs Chrome-based every 12 hours. So if you approve these strings, you get a PR on every 12 hours based on this schedule. Obviously, you can change this just in the crowd-in in the GitHub file to be something different. But yeah, this is the example you have experimented with in the past docs of the sessions. So perfect. That's exactly what I wanted to hear in a sense because if it was a direct commit to master, it could be a huge mess in terms of security. For the example, the permission that you are setting in that application are not necessarily the same as in the repository in GitHub. So we can have some desync at that point but it's also because the translation are very dangerous in Jenkins. They are considered as trusted code most of the time and we got some huge issue in the past in terms of XSS because if you are able to include any payload inside the translation, it will impact everyone in a sense. So that's pretty interesting to see that it's based on pull request and nothing else. Right. And so let's highlight just, here's a specific example. So schedule build six days ago received a pull request from, let's see, from GitHub Actions. The bot submitted a pull request that had these changes in it and I had to review them and then decide to merge them. So it felt to me very similar to what I do with dependabot where I say I look at the change and I have to decide if I want it or not and if I don't want it, I can close the pull request. Yeah, so I like the pull request workflow very much because it insulates the develop, it requires me as the maintainer to think about these translations but has the benefit that the submitter hasn't had to work through the formatting and the character encoding and et cetera all in order to get their pull request submitted. And yes, notice non e un tempo di generazione valido A has an accented character and my Italian is still embarrassingly poor. Yeah, just a note on authentication. The workflows are currently using a personal access token generated by Crowden to use as secret in your workflow. Similarly, how do you use other secrets in workflows? It's basically nothing you expose anywhere. And that's similar, if I remember correctly to the technique used by continuous delivery, used by CD, is that correct? Now, there was another question which was how do we authenticate users to Crowden as an application? And I think there the recommendation from Tim was let's just use GitHub, use GitHub and what's the other, he cited an example. I think it was a GitHub auth like we do somewhere else. Oh, dear, where else? What's the other place? I forget. So in other words, let's avoid using avoid Jenkins LDAP because we'd rather not manage a connection between Jenkins LDAP and the Crowden server. Yeah, based on the example Tim and I think it was Damian from the info team gave me it would be compatible out of the box anyway because Crowden doesn't support LDAP but more SSO here, which our account start service isn't much compatible with anyway. But I think using OAuth2 from Google or GitHub that's what we have enabled at the moment would work out fine enough for the ordinary user. Obviously, you can still sign in with an email and password if you want. But me, for example, I'm just using OAuth2 to sign in because that is fine enough for me. Excellent. And Vada, since we've got you here is there anything we need to do to engage the security team in assessing how this is being done, et cetera? If we just use GitHub OAuth2, I assume no issue for the security team or do we need to do a review with you? As long as it's creating some pull requests I will say I do not care at all. If you want to manage a username and things like this directly in the application I don't care because the impact at the end will be through the pull request. So if a maintainer approves a change you don't care where the change is coming from in essence. Great. Excellent, thank you. All right, any other anything else on localization and crowd-in enterprise? Thanks for the presentation. All right. Well, and Alex seriously, thank you very much. I'll keep saying it how delighted I am with how that feels. All right, I think we're set for today then. Anything else that if not, oh, go ahead Vada. Just perhaps a question concerning the pull request 300 from me in script security. What do you expect in term of action at this point? Because that was a topic that was created or I think it was discussed for the first time one month ago in the previous week's meeting in two weeks ago. Why it was coming there just to understand a bit the context? I just brought it up because it had been on the agenda for an extended period and that was the only reason I raised it. I don't see that we can just leave it as is because I don't think we've brought it to resolution yet. How we want to do it right. Jesse's view is he just as soon we make no enhancements to that page. Others view is hey, that's a good page to improve and there's a lot that could be improved. Yeah, just to be sure if there was any real need or things like that to move it forward right now in a sense. So thanks for the clarification. Great, thank you. Perhaps to set expectation, I do not plan to work on that aspect at all at the moment. So do not expect me to have a status next time with positive news, I will say so. Well, and I think I think we can we can just drop it from the agenda because it's we've we've brought it to resolution to the point where it's it's it's paused and it won't proceed forward until the concerns are addressed. It's OK. Great. All right, thanks everybody. Thank you, Mark. Thank you. OK.