Jenkins UX SIG Meeting 29 Jul 2026

Welcome everyone. This is the Jenkins user experience special interest group. Today is the 29th of July, 2026. Uh let's get started. So, right now the big the big activity is work on the experimental UI. There are three different pull requests in Jenkins core that are in progress in draft mode, draft form, considering are we ready to enable the experimental UI by default or even a portion of this experimental UI? And then there's the scrollable side panel, which Jan has ready and needs review and experimenting to be sure that it's it's working well. It has passed the plugin bomb tests. It needs to still run with acceptance test harness. So, good place for those of us who are involved to take a take some time and test. Go ahead, Chris. Is which one? >> Uh the this one, okay. Okay. >> Yeah, so it's the >> It's the second one, right? Enable >> It's the last one. >> Oh, it's the last one, okay. >> There, I'll just move it up. That way we got it. >> Let me play around with it. >> Great. So, this the the second and third as listed there are draft. And let's say this one is a different activity. Because what it's talking about is um improvements for review. Right? Because it's really not draft. >> Yeah. >> Great. Now, October 2026 is still the hope date to enable some portion of the experimental UI. Last time we talked with Jan, the sense I had was it might only be managed Jenkins, not the experimental run UI, but we'll watch and see. We have had some work completed. The status icons have been updated now in the weekly version of Jenkins. Not visible in LTS yet, but you can see what it looks like here. Uh the old look is here and the old look would show you the the status of the previous job in addition to the current job. The new icons show the current job only, not trying to embed both the status of the previous and the current. >> Uh can I ask a question >> Sure, Chris. Go ahead. >> The 41st item like we just discussed before for the experimental feature, I got a question now. So, have we tested on some kind of like edge devices yet? So, because the I remember there were some complaints before when we were using new features. It No, it looks nicer. It works very well when you have a lot more resources, but when you have edge devices like some computer like that's like um maybe um just um doesn't have a like so much CPU or GPU or whatever. And it may not work as well in those situations. >> And so >> So, when you're when you're saying edge devices, you mean like Microsoft Edge or do you mean edge as in Internet of Things? >> I just mean like um is just Well, in case like for some computers, they don't want to use so much resources like not enough CPU. For example, it would not work as well in those cases. So. >> Yeah, all right. So, it's I'm not aware of I know that Jan's work is done on a on a uh a good performing MacBook. >> Yes. >> And when I do my testing, I'm sitting on a good performing Windows machine. So, I'm not aware of anybody who's doing active testing on low-end or slower computers. >> Yeah, cuz I don't have one either. Otherwise, I could test it, but I just don't have the resources to do it. >> Right, understood. And I think that's where we'll have to rely on others in the community who may have access to slower machines. >> Okay. Should we like do a call of action to see if anyone anyone with those like computing resources can help? >> We could. I've not had great results in the past with with those kinds of calls to action, but you're certainly welcome to do it. Yeah, that'd be great. >> Cuz like I was thinking like it if we warn people before I have time, maybe through a call of action, even if they complain, they wouldn't have like so negative reactions like before. That's what I'm thinking. >> Okay. Yeah. >> a thought of mine. >> Yeah, that's Chris suggested inviting users with slower machines to test the new UI, right? Good. Okay, very good. >> I would also I would also >> add to that um depending on the Jenkins instance, like for instance, I recently, as you all realized, started using or jobs. Um they do weather by default. And just loading the UI in my instance is catastrophically slow because I've not disabled weather yet. So, some of that slowness could also be a false positive due to a default in In my opinion, a misconfiguration of Jenkins, but it's a default that when you configure things like org jobs and other stuff the the weather being enabled recursively calculating build health um is a significant performance hit on the UI when you load the page. And and so just to give you an idea um in my Jenkins instance which has about 1,500 repositories, I realize that's not most people's probably, I don't know, but um with weather enabled, a page load can take up to 10 seconds. With it um disabled, it's fractions of a second, almost not noticeable. >> Okay, so yeah, so your your installation is sized similar to what the what the the ci.jenkins.io is sized in terms of at least job counts. So usual yours was when you said 1,500, that's jobs or is that organization folders? >> Uh no, 1,500 GitHub repositories. >> Okay, repository So that that is similar to Jenkins ci.jenkins.io. That's good. >> If you're talking about uh job count, there's 4,000 multi-branch pipelines. Uh which uh just exponentially increase at probably like 50 or 60,000 uh classic workflow run jobs. >> Got it. Thank you. Okay. Yeah, so so we've got something similar with 2,000 or 1,500 plus repositories on ci.jenkins.io. We manage them with a relatively small number of org folders, but I I'm reasonably confident we don't have weather reporting enabled there because on the plugins org folder, it would be a thousand jobs rolling up. Yeah. >> Yeah, and I just wanted to note it's a default, so like unless someone is very Jenkins savvy, they might not even know it's a performance problem. >> Good. Okay. So, and what you've done is you've disabled weather reporting though enabled is the default. >> Uh well, so all my org jobs I haven't gotten around to disabling them yet, but >> Oh, okay. >> fortunately the org jobs are pushed into a folder that has the weather disabled, but when you go into that folder, it's you're just going to have to wait a while for it to load, but all the other pipelines uh in my Jenkins instance are pure uh job DSL configured multi-branch pipelines and not the org job. And those job DSL configs have weather disabled. I just needed to go back through and disable it on our org jobs, but every time we merge, we actually hit GitHub API limits for those org jobs cuz they do a scan and org scan. So. >> Makes sense. Okay, so weather reporting on folders is a is a performance hit and while looking at performance or looking at places we could offer performance guidance, that's one. Good. >> Uh I would also say when you're The reason why I piped up about it is you're you want to invite people with slower machines, you want it's worth asking them, you know, about that bit of their UI configuration, whether or not they have weather enabled or not. And if weather enabled, which setting they have in their infrastructure. >> Makes sense, yeah. >> Good. Thank you. Thanks very much, Sam. Anything else in terms of updates on the experimental UI? >> Uh should I make the call of action? Is it okay? I can do it. >> Yes, you're welcome to, Chris. That'd be great. >> Okay. >> Excellent. Thank you. All right. So, in the needs review world, we've got the the sticky build bar and independently scrolling side panel that had been mentioned earlier. And Marcus Winter has a a pull request for the experimental agent page UI. I've not seen much traffic on this one recently. It was opened in April. Um so I I suspect he's still interested in it, but it needs needs more work. Yeah, it has passed bomb. It hasn't yet passed uh acceptance test harness. >> Is there one ready for review by UX team? >> Well, so the the side panel independently scrollable is definitely ready for review. >> Yeah, but how about Marcus's one? >> Um Marcus's has already been reviewed by various members of the UX team and is certainly the question I think for me is what's next? >> Okay. >> To get it all the way to merged. >> Yeah. >> So, it's had last last noise was about a month ago. >> Yeah, it's a long time ago. Yeah, and this one we'll review, okay. I could do another review of it, too. >> Great. That'd be that'd be super, Chris. >> Okay, yeah. Let me do it over the next few days. >> Okay. All right. On the work to be done, the things that I'm aware of are are mentioned here. I don't know that we need to mention them again. Uh we do still have an open draft pull request to the cloud stats plug-in and roll strategy plug-in has seven draft pull seven pull requests open from Tim Jacomb. So, there's there's still plenty to do there. But, that one's relying on the roll strategy plug-in maintainers to review them. >> Who are the maintainers, do we know? >> Um, I don't recall, but we could certainly easily find out. >> Okay. >> It's a plug-in that I don't use and I'm not not especially interested in. So, I let's see. So, maintainers Marcus Marcus is the the most active one of the maintainers. >> Is that Is that list sorted by activity or is it just what was in palm? >> Uh, it's sort it's sorted by I think what's in the repository permissions updater. Definitely not sorted by activity. >> Okay, sounds good. >> So, if we look at at the commits, recent commits, you'll see Marcus Winter is the is the most common committer, particularly for merges. >> Yeah. >> All right. Any other items on the on the new on the experimental UI? If not, then let's go on to the next one, which is generally work on the web UI. So, we currently have 44 open pull requests. And we've had 11 pull requests merged since the last time we met. Six of those 11 came from Jan Faracik. Uh, two from Oleksiy. One from and I cannot pronounce that name correctly, so I'm going to skip it. And likewise here. >> the zone. >> Okay, great. >> Uh that that the last one is like band ways like strange year thing. Okay, I did it. >> Thank you. Thanks very much. And then that I missed one in my Oh, and Now, that's Young Bin. Oh, yes. This one No, I I I have missed one in my count, but trust me, it's good. In the past, we've had cases where Jan was the only one committing web UI improvements. Nice that we've got a larger group contributing now. >> Yeah, I I have no idea where they're from though. >> Uh me, neither. I I have guesses based on the script they write with, uh but only guesses. So, in terms of work in progress, I don't see it didn't as I was reviewing these see any here that needed us to discuss them. Are there any of these that either of you are interested in or that cause you concern? >> Um oh, one general question. Like um do we have any process to like um to remind um the contributors about the PRs cuz some some of them like I'm not sure if if you cover some of them. >> We we don't really have a process that reminds contributors other than asking. Right now, the primary reviewers of UI changes are also the same people who are focused on the new UI. >> Yeah, cuz I'm asking because like for some works, they have like something that is kind of not very user-friendly because like um they would just like if a PR is down, they would just close it automatically. Like say after a month or two. I don't like it. >> Yeah, right. And and I definitely don't want to do that. That would be that would be a a strong a strong opposition from me if we chose to to close stale pull requests. Just because they've aged doesn't mean that they're not not useful and interesting and several of these are are actual fixes and they're useful fixes, but I am not comfortable saying that oh, we're ready to merge this without having input from Tim and Jan and their deeper experience with how the UI is structured and why it's structured that way. >> Yeah. >> So, for me I'm I'm just sitting willing to willing to test them and see yes, it behaves well. Yes, it works okay in ATH and in plugin bomb. Those are good things, but I I don't want to just blindly merge them without the confidence that the UI implementers agree that that's a direction they want to go. >> Okay. >> All right. Any other topics we need to bring to today's meeting? >> Um not about UI per se, but I'm just thinking like for maybe for Hacktoberfest, like should we start working on something cuz like um it's August almost. Cuz like normally we have a uh Yeah, normally we have a campaign I just to have we we organize a campaign. Maybe I'm not the one involved like on on most recent ones, but I remember like there were some documentation um on the prep for the event. So, should we do we do like something similar? >> Good good question and I'm not I'm not sure that I'm ready to have Hacktoberfest contributions coming in for Jenkins user experience. For me, that feels the skills needed to do effective UI contribution in Jenkins are fairly obscure and need some time to develop them. >> Okay. So, maybe we should focus on something some other aspect of Jenkins then. >> Right. That That That's my preference. They're writing writing automated tests. Okay, that that I can see being being helpful. Doing finding things that make sense for new contributors, that feels helpful. >> Okay. >> But for me, saying that we're going to have Hacktoberfest contributors working on you user experience I'm I'm hesitant to spend Jan's time or Tim's time or even my time trying to guide them on hey, this is how you do UI development. They're They're They tend to be short-lived. I'd rather not spend their time in Jenkins UI. Let's put them something closer to core Java, closer to easy to understand and comprehend. >> How about the docs retooling? Cuz we've been stuck with it for a while cuz I need some some help maybe on that. >> Mhm. Yeah. >> And create some kind of tickets for people to work on. So, docs cuz so we can talk about doing the docs thing later next week. >> That And that that sounds more reasonable to me. >> Yeah, sounds good then. Okay. What's the current back end for docs? Is it make docs or something else? >> No, it's Ruby. >> Ruby? >> It's actually Asciidoctor. Today, it's Asciidoctor which is is a Ruby a Ruby generator going towards Oh, dear. I should remember which thing it's going towards. Chris, is it Gatsby and >> Uh no, just React and Vit. >> Uh okay. >> Yes. And uh oh, hang on. And that's um what's that called? I suddenly forget. Um, it's a documentation site. It's called Let me Let me find it. I don't remember. Oh, um, ask it I know I know that's not I don't remember. I don't know. Let me check. Ask it talk. >> And your pain points with docs are about them being out of date or is it how they're organized or is it switching the back end? What What were you thinking? I'm just curious. >> Uh, it's just like um, cuz Austerlitz is not being maintained anymore. Actually, so we're thinking like just to update it um, um, the like the entire tooling. We have been doing it for a few years. Actually, we got rid of some of the code. But um, yeah, uh, the results were not so good. I can say uh, but yeah, we um, but we only need to one more summer through to finish it though. Cuz it's not supposed to be like uh, too involved. >> Right. Yeah. So, switching the back end was was certainly there is there's certainly also plenty of of missing content, Sam. Places where missing content or an inaccurate is less of a concern, but there lots of places where content even from the wiki uh, might be edited, revised, improved, and copied to the and placed on the site. But again, those things I'm not sure they're great for first-time contributors because you need to know Jenkins well enough to decide what's what's right and what's not. >> Yeah. >> That makes sense. >> I don't even remember which one you used cuz I it may be off like off style already. But see, I think it starts with an A, but I don't remember the name. Let me see. Gitbook is not Gitbook. It's um How come I can't find it anymore? Documentation framework, right? Hang on. And then >> You mean Ask your doctor as the generator? >> No, it's not. >> That's It uses Asciidoctor. >> So, the documentation is called Antora. tooling Hold on. Let me Let me do one quick fix quick quick quick check. >> Okay. >> Just give me one a few more seconds. One minute. >> Great. Super. My bad. >> I should know that things by heart, but I know I don't. I know. So, sorry. Git home. Let me check this. info installation and talks I'm sorry. Git home. and talks Oops. talks Yeah, right there. So, um Oh, it's called Is it called Antora? Yeah, Antora. >> Oh, right. Right. Yes, it is. >> How How come it's not like no one uses Antora? Like it seems >> Oh, no. If you look at Well, I think if you look at at many sites, you'll find a bunch of sites that are on Antora. Um many many of the Yeah, at least I see sites that look an awful lot like they were generated with Antora. >> Okay. >> for version documentation sites. >> Yeah, we have to like update we have to like really get this completed and uh >> Mhm. >> Yeah, cuz like the old site right now like when you build it when you try to get um the security documentation done quickly, it takes forever. As in the >> It's like if we >> As in the complexity for inserting new documentation is hard, but once it's written it's easy to update. >> Yeah, cuz like we want to split into two parts. Like right now it's like uh it's not version controlled, so we have no version by version like about like for the documentation. And also like that that's one thing that that's making the process like more lengthy. So what we want to do is like split the documentation into two parts. One is version controlled part and non-versioned. Uh which means that for the documentation six for example like for the most recent releases like 2. uh LTS release sorry it's 2.568.2, right? So for that one like um I think it's going to be released and as of the last one was 2.568.1. So for So what we want to have like for different documentation different versions diff- different versions with different um different um documentation for it. So when you like use select the different versions, you'll see if you select a drop down you'll see something different corresponding to that release. But um and also one one part of it that's non-versioned. So for the non-version part it can be be built quickly. So uh that would like speed up the entire process. Especially that that would be useful for the security team because like sometimes when there's security releases, when they want to push out the documentation quickly so as to minimize the gap between like like people can can exploit the vulnerability. I I'm I'm I I I need like um It's like um they they need like a very tight scheduling to get it done in those cases. But right now like for a build itself, it takes a few minutes, I think, even on my computer. So that's not so desirable. >> Yeah, so time What you're saying, I think, Chris is time-critical deliveries. Like like security on patch day. Got it. >> I just don't have the words ready yet. Yeah. That's That's it. Yeah. >> Got it. Anything else that we need to be sure we discuss today? >> Oh, yeah. So um for the UI UX, um I I I may It may be a good idea for me to between and bring up the GSoC project um we are having for the stories um feature cuz like if you go to stories.jenkins.io or maybe um Is it like Is it stories.jenkins.io/stories, right? Yeah, this one. So if you go to this site, um right now it looks really dated. So what we're doing at is to like uh we want to make it look And also we we we toy with it cuz it wasn't built on Gatsby. And for some reason Gatsby was acquired uh I I remember. But uh because it was not very like profitable to like to keep it updated for a while. It wasn't updated from React 18 to React 19. And because of that of that issue like we wanted to migrate the website itself away from using Gatsby because like we have control over like the timelines. Um so um what we have right now if you go to um We don't have a preview site yet. So that's what I'm talking with the infra team to work on right now. So if you go to like Jenkins uh github.com/ uh infra uh oh no uh that's Jenkins and hyphen infra. >> Uh-huh. >> Uh so yeah hyphen infra uh stories. So we can go to the um the pull requests. You guys see a bunch of pull requests that are for uh for the new branch which is GSoC 2026 which is the thing we're working on right now to be like updated look and feel. Also to wing for the project. >> Great. And so this is part of Google Summer of Code. You're planning to have this ready by October September October when the when the the GSoC project finishes. >> Yeah so we can have like we have some issues in that like repo then. That's when I need it to be ready. >> Great. All right. Any other topics for today? >> Nope. >> All right. Let's call ourselves done. Thanks everyone. The recording will be will be available in 24 to 48 hours.