 Awesome. Let me know someone if that's not quite large enough and I will make it so. Cool. Welcome everybody to the 11th Jenkins UX SIG online meetup. We got a couple of standard items here and then some new items to go through today. So first agenda review and agree on agenda topics. So anybody have anything they want to add? I see we're just jumping in there and doing that. That's awesome. Feel free to do that as we go through. Can you paste the link into the SIG channel? Sorry, I can't find it. Can you just paste the link to the document in the getter channel? Oh, it's just this document. Sure. Actually, Felix or Everista, would you mind doing that real quick? Sorry, what? Can you paste a link to this document? Yeah. I think I'm signed out. Easier. Yeah. Thank you. Cool. And then we always do this as well, introduce any new participants and kind of discuss their interests. So scan through the list here. Forgive me if I'm saying your name incorrectly, Sumit. Are you there? Hi, I'm here. I'm not saying it correctly. So basically, I just wanted to explore how the UX SIG is performing and like, I mean, basically how you, what tasks are you working on and just getting myself familiar. Awesome. Welcome. Sorry to put you on the spot. Just wanted to say hi and thanks for joining. And I think with that, we can go ahead and jump into the first item on the list and we got a lot to cover today. So I will try to be timely with this as well. So we're going to kick off with a quick design deck here. Take a look at some items that have been improved and worked upon since the last SIG meeting week before last. So the context for those of you seeing this for the first time or really the first time in a while. Each SIG meeting, we have a deck like this that kind of summarizes some of the design items. And we also have a dedicated resources Google document that lists everything that we share in every meeting. So everything's kind of collated and you can reference back to this, but to get some more context for the overall project, there's some slides in here that are here for every deck if you want to check those out. And then we can jump into some, there were three items on today's list typography considerations, color palette improvements, and some sidebar design improvements. So first let's look at typography. We had as of, I think it was probably February in this SIG, we shared the first iteration of a sort of type scale, sort of trying to define consistent or standardized typographic hierarchy for the Jenkins interface, which we have since simplified and we've, of course, merged some really simple but really effective and impactful improvements to typography in Jenkins as well, which is great. So all this topic is for today's call is just to say that work kind of continues, right, it's not, it's not just a checkbox and then done and we don't think about typography. It's one of those elements that that impacts just about everything else in the experience. So in the background, or I suppose not in the background but over here in between meetings, things are things are happening here as well so I spent a little time thinking about typography in Jenkins, trying to come up with a more effective way of categorizing typography and typographic styles. And of course we had previously decided to lean upon system default fobs for rendering type in Jenkins interfaces. And as a result, one of the tasks I wanted to accomplish over here in my design software was set up all of the type styles that we have going in the three most common system default fonts, which are San Francisco, Segui and Ubuntu. And in that way whenever a new component is being designed, I can easily swap between those three fonts. And get a better understanding of what that component or that element looks like for users of different, different operating systems. So that's not something really I can, I can show very quickly without a more prepared demo. But it's just to kind of highlight that that's something we're being mindful of. This is the type scale in its current iteration, right? This is something that will continue to evolve. But fortunately it is becoming more sophisticated as we solve, as we continue to solve problems. And it's becoming a bit more realistic as time goes on as well. And as I mentioned, you can always go back and look at the stuff after the fact. So I'm going to kind of move quickly because we've got a lot to cover. The second topic also, I'm just broadcasting here, which I apologize, anyone can interrupt me anytime. As a reminder, we have an open conversation format here. The second topic is updated color palettes. Absolutely. You brought to my attention the need for for more detail around around colors in the last meeting, which I really appreciate. We had that first iteration of a color palette, it was okay and it got things started and now it was time to push that further. I don't yet have a color schema for you for data visualization. I know that's something you were kind of wanting and I will be given that to you soon. But first I wanted to improve the format of this. I'm sorry, we're going to say something. Oh, okay, I thought I missed something. And so I wanted to take a step back and improve how we do, how we look at colors and Jenkins and also provide some more detailed resources around colors. So, with that in mind, we've got some color categories here, each category contains multiple swatches. And what this does is it helps us to kind of establish a framework or framework for discussing color and how we think about the different colors relate to one another throughout the interface. Each swatch, this is not a full palette of course is just a few swatches. But each swatch now provides the hex value for reference, right, which is an oversight from the original version, but now that's added in there. And the updated resource also emphasizes visual contrast. So details are provided about the contrast ratio of common color pairings, right. So it's really important when you're referencing these colors to. Somebody says something. No, sorry. No worries, I keep hearing things. Sorry, too much coffee, perhaps. It's really important to think about how these colors relate to one another in the contrast that we have, especially when it comes to text but also just general UI elements against their backgrounds. One for each color here is provided the contrast ratio details for for common color scenarios, right. So, for example, we have Jenkins blue here. If this is used as a background and the foreground is text white, then this contrast ratio is too low. This fails by most measures. The temptation and the inclination usually would be to put white text on this blue. So that's why that particular pairing is is laid out here to provide that detail. And the goal is to show those common color pairings what people would would typically default to logically and myself included and and provide a little more context for whether or not that works inside of these resources. The contrast ratio as a complete in expert. So would you then use white to black text over that deep over that Jenkins blue color. I'm not sure. So great question. So, in this case, when we see that the contrast ratio is, and this resource I should point out needs a little more work right like this says that this fails, but it doesn't help you figure out what to do instead. The answer to that question though is that this this blue really shouldn't be used as a backdrop to for text. Thank you. Okay, thanks. So, so that's the hint to me, if it's Jenkins blue behind it as a as a person placing text over that it's going to be very very difficult for to be visible to the user no matter what color of text I use. Correct. Yeah. Thank you. And like I said, you know the resource. I'm still working on it here. And basically, I want to make it real easy and I'll link some other tools for people to go and test out other combinations, you know, like, like if you were wondering what if black would work. So, work in progress but hopefully we end up with some really thorough useful stuff here. And what we're seeing on screen now is an example of one of those categories, right so this is not every every color that we'll see in Jenkins. By any means, but what we do have here. And as I mentioned earlier, earlier five color categories. And this is the general UI elements color category. We're showing the visual contrast details for common pairings what people would would usually be inclined to try out together. And I'll also add on here sort of a link to, to other tooling that helps you test other combinations. And they'll be one of these sheets for every color category. So anyone have any thoughts or feedback on that this needs some finessing, in my opinion, frankly, but anyone got anything there to share or discuss. Okay, cool. Well, I'll keep you all updated. The final form you know this or the more finesse form so it's a little easier to understand I think I'll share in the next thing. And the next thing for this slide deck and then Felix will jump into yours. Your demo there will be just that we're thinking about design improvements for the sidebar. And the place to start for that is to kind of try and define the anatomy of that side panel. Right now it's for power users and people who are very familiar with Jenkins it's really clear how it works, but it's not always clear to new users. It can be a little bit amorphous what what elements are which and how they, how they interact and relate to one another. I think there's a comment here. Let me just check that. Thanks for that. Let me see here. So we're trying to think about. We're trying to define a structure right because it already exists that panel has has logic to it. It's just not always very intuitive. So this is by no means done. This is something we're thinking about and working on. And this is where that logic stands right now in an ideal world, you know some of this is not technically feasible at all yet. Having these groupings I would like to say something I would like to to call attention to them to the distinction there. Can you zoom in the in the sidebar please in the tasks. So we are aware of many people is aware that there are problems in the sidebar with mixing of two different things. Families of items which are navigation links and actions. For example, it's confusing to have go to these configure page next to the build button or next to the build now button. So, yeah, so we've Joe has the science and concept for separate how do we can separate tasks that navigation here. I am afraid we cannot implement it right now because we don't. There's just not infrastructure on the Jenkins I mean on jelly or whatever to do this but this is something that we propose and if something if somebody comes up with a way of how we can start walking the way towards this. Please speak up. Or we work on the initiative. Yeah, I would be happy to improve this panel, because this is an idealistic state. And in some cases, for example, for built view becomes really complicated because many actions tend to additional controls. I'm not even speaking about get plug in which may add something quite five or 10 actions. Unfortunately, yeah, there is an issue with that. So, I would be happy to regroup it to remove it and maybe even hide the panel by default or maybe whatever slider so that it doesn't consume too much space when it's not needed. Yeah, for me, the best thing to be to allow people calling the task or setting up the panel calling or invoking the task to say this is an action or this is a navigation. So, I think that would be a start for me to, but I don't I don't know, maybe we can maybe we can discuss this offline, but I really will have the vision where we could improve. This is something we can improve. And I mostly, most everybody agrees with it. Yeah, we could. Awesome. We just categorization for the configuration screen. So, if you go forward and introduce it somewhere else including the panel. Plus one. Great. Sweet. I'm going to stop sharing here and head over to Felix. Okay, yeah. Let me. So what I'm going to do is show you show everybody a bit of what my current implementation of the sideways based on these changes. And we will be looking for feedback. Okay. Let me know if everybody can see my screen. Yeah. Okay, great. So, I went ahead and implemented Joe's designs. And you'll notice that this sidebar takes a bit more space. We have added a bit more vertical spacing between items. They are now each hyperlink is now 40 pixels tall. We think this is a reasonable touch area for people to interact with, because the previous previous one felt too cramped. I mean, if you see there, this is a really, this is almost crossed off, crossed off trophobic, right? So, problem, it may push these panels a bit in some screens. That's something that we appreciate feedback on this, but we asked to keep on open mind on this one. So, you'll see this is how it looks in a screen with a bit more items, with a few more items, for example, on this job. Yeah. We also have improved the active status for the current page. We think it's a bit more clear now, more visible instead of just bold text. We also look into the, into how to render nested items and nested elements inside of this. So, especially, for example, the credentials one, the credentials plugin provides some sidebar entries with different levels of nesting. Instead of marking all ancestors as current, I think we, this is more, this is lighter. So, we, I will probably be creating this PR tomorrow morning. So, I, we ask everybody to please give it a try. Yeah. And we await all feedback. This is one of those, oh, sorry, gone. Sorry, no, please go ahead. I was going to say this is one of those things that, you know, on paper can seem kind of, it can almost seem like not not a big deal, but really over the long term when you're interacting with this panel as much as a person does. This can make a huge difference in just general usability and having proper interactive states reflected here. So, pretty excited about this one, but definitely open, you know, open to feedback and want to hear which all thing for sure. Definitely. Also, and regarding the implementation of this, this is a bit interesting. I think this can be a bit interesting. We, what I did was, first of all, if you, if you look at the CI.jackings.io example, you'll see that this, both in each image, these are two different hyperlinks. It doesn't really make much sense. So what I did is I reworked the task.jelly template to have a single hyperlink to wrap everything. So I think it's a bit more usable and now when the user tabs through this, it's a bit more accessible and a bit more intuitive. So, I don't think this will break any plugin, any plugin, I will try to identify, do a bit more deep search of plugins that has a custom action.jelly. So if anyone is aware of any plugin that does weird things with site valentries, please let me know as soon as possible. I appreciate it. Also another call for help. If anybody, I know that there are plugins, that there are places where the site valentries have a arrow, a drop down arrow, like this one. So if anybody knows of... Just in case you are not sharing the screen, it was a bit difficult with the CI.jackings, but now it's clear. You are still sharing the localhost. Okay, I don't know why I tapped that. Okay, so now you can see my screen. The localhost one only. I think you share only a tab or things like that. Oh well, let me try to share again. Okay, so what I wanted to say is that both the images and the levels are within the same hyperlink, unlike before. So I needed to change the task.jelly template for that. So if anybody is aware of any plugin that does weird things with site valentries, please let me know. I've been searching. I didn't find any relevant plugins that did that, but you never know. And also I know, I'm aware that I think some plugins have a drop down arrow, like this, a contextual menu on the site valentries. So I'm looking for site valentries without a contextual menu. If somebody knows of a specific one to test, please let me know. So, yeah. So that's it. Any feedback? Any comments on this? Would it make sense to forbid some things like a drop downs or I think even the hierarchy I never seen it before. Does it really make sense to have a hierarchy in this list on the left side? For me, at least it, I find it quite helpful to have credentials have hierarchy there. Because it at least it helped me understand there is a nesting of this. So the example he shows here was helpful to me. However, I'm open to also opening the credentials panel directly and using it. Personally, I have never understood where credentials has to be on this page. Pretty much the same for local resources because all of it can be accessible from the managed page. In some cases, there was a workaround because the managed page requires administrative access to you. But I guess we partially resolved it with system read permission. And maybe we could have another page for such beats so that we don't have to display them at all here on the landing. But that will not solve the problem for credential because credential is not linked with system read. It just credential manage that is a completely separate permission. So it will require additional magic about that. But from user experience standpoint, if you can remove it from this panel entirely, I think it would be better because these items are not accessed often. Please correct me if I'm wrong, but I'm pretty sure I have not accessed them from these pages. No, no, I feel the same, at least from my personal experience that hierarchy seems weird that year. Just concerning the one link instead of two, it's something that is really nice. So if you can manage to have that implemented, it could be really good, especially in terms of accessibility. Yeah, that's something I want to touch right up to this, but that was one of the goals. And with the switch, does the alt text still survive so that those with visual impairments will be able to see the alt text that helps them? It doesn't switch to not showing alt text, I assume. So, the thing is, if you have the hyperlink and the label, if you have the image and the label inside the same hyperlink, you can just have no alt text for the image because the hyperlink text should be meaningful enough. Before it was a hack because it was needed because the hyperlink, sorry, the image was a hyperlink that had no text. So you could hover over it and say, okay, what does this icon do? But now they are part of the same entity. So a screen reader, whatever tool, just would go over and read the content of the text. For example, they would go over here and read manage Jenkins and ignore the icon. Excellent, so an improvement in accessibility. Thank you. Yeah. Just a thought about the CI Jenkins.io, if you can just open a tab to come back there. As you have seen, perhaps there is a lot, a lot number of executor. You can scroll down a lot to see all the things. With an extended height for the sidebar, do you think it could be a problem with that? Especially if we think about the future and your tendency to put more space around the things for the design. Such page could be even longer. What do you think? So it's a balancing act, right? It's a, because it is a fundamentally good thing to have slightly, maybe not, maybe not even as much as we have reflected there. But it is a good thing to have a more spaced out menu. However, I totally get your point. The design of these executors and how this is reflected is also going to be reconsidered. So we might be able to, for lack of a better expression, save some height, some vertical height in those as well. It's hard to say right now, but at the end of the day, if someone has a really complex configuration with a very tall sidebar, there's sort of a feeling out there that people don't like to scroll or that that breaks the experience. From what I understand, you know, that's not necessarily true. So it's something I'm being mindful of for sure. But I think it's also somewhat unavoidable in this project. Yeah. I also think it could be argued that is that the correct place, you know, to have the executors, where to place the executors list. So for example, can you, can we be creative? Can we maybe have a right panel where we share that it's collapsible, where we can show the old this item? So can we keep the left panel your reference navigation? So I think that that opens that can open and can lead to a bigger discussions of whether the panels should actually exist and continue to exist in the same shape that they do right now. It's a good question, because it's not on the matter of user experience is also a matter of performance, because on big instances that this panel creates a pretty high load on the server. It was even worse when this panel was synchronous when we had queue logs, etc. Now we have a Qcash and some eventual consistence on this panel, but still it produces quite a lot if you have hundreds of users connecting to the main page. Yeah, I really like the idea of the right side were collapsible with the executors I was thinking of a very similar idea to what you just said, Felix. I think that could be something to think about. Yeah, I think, but I think that's, I think that's, I think we should kick down the future, because for example I also been playing around with the idea of making. So, everybody's favorite panel, which is the trends that we all know what happens when, when this gets too wide, right. I've been playing around with the idea of making this collapsible to the to the side. So maybe we should be thinking about that. But I think that I think Wadek, I think you're, you're right, we are, we are on the track to add vertical spacing to many places. But for example, here, maybe here in the real history, that argument has more impact, because this is something you can see at the glance, but for example here on as soon as you have something on the build queue, you just will not see anything on the executors this right. So, as you said, I think it's a balancing act. I don't think we have a good solution right now other than because we need to see to what extent we should limit ourselves, improving readability, improving capacity to interact with this panel and improve it with balancing with the fact that we have this piece of legacy UI with it. Just a thought in addition, if you want to break no workflow of people to have like Gmail a condensed mode, it could be also useful. So that you remove the vertical space for people who really want to have very dense information and for the rest of the people to have the more beautiful version. What do you think? It's an interesting idea. It's out of scope for right now, but long term, I think it's an interesting idea, especially since there are so many pieces of the UI in general that look like this. The same kind of goes for the panel's topics and these ideas. I love them as ideas, but I don't think we'll be able to get to them very soon. But it's interesting. Yeah. I'm looking at that side panel and just like none of that really needs to be there. Who clicks on the people link, who clicks on my views, who clicks on new view and credentials, local resources. Like how often are they actually used in the. I have talked with some friends that are actually power Jenkins users and related to cloud is or to the biggest community they just sees admins. And they say for them the biggest problem with Jenkins was the, what the hell effect about what I especially for this site navigation with when we should I go here when should I go to the slash manage page. So, but I think that's a far bigger reach than what we can do here in this. improvement. Yeah, you know, it's very true. It's also true that we could be mindful of those things for the long term as we're making these style improvements to so this is still very valuable feedback so I appreciate it. It's a small step at a time, because if you compare current way out with one we had one year ago, you can already see a lot of great improvements. Yeah, thank you. Okay, I think it's, we have 25 minutes left if there are no further comments maybe we can go ahead and move to the next point. Okay. Next, I'm going to next topic is, okay, for some reason, introducing accessibility epic. Okay, let me share again this time my visual studio call the screen. So, we cloud is we have done some we have been doing some accessibility research and found some accessibility well Jenkins as a whole has severe accessibility issues. Most of them are very, very tough to solve. For example, it's really difficult to make accessible widgets such as drop downs and everything because they depend on your UI code. So, that said, we identified several issues that can be easy, even most of them new friendly. And so I will be creating accessibility epic with these issues. And we will leave them there. And eventually, if we see no open circle contributors, sorry, some community contributors to pick them up. And implemented maybe we will be we are cloud is we will start solving some a few of them but we think are great candidates for no we friendly tasks. So, for example, some of the of these are indicate the language of the page in the HTML document. And it will fix the skip navigation skip to content navigation. This should be product straightforward. This one does not apply anymore with the navigation changes and labels some improvement to the login screen and form. We can use the new buttons on the login buttons. Okay, so provide a warning before logout. I think this should be somewhat easier tasks. So I just wanted to introduce them and anybody see accessibility problem actually accessibility problem, especially if we if it can be categorized by the web accessibility standard standards with severity and source of problem. So, yeah, I think that would be the place for this. Any comment on this. It would be nice improvement in general. Also, we had a number of contributors who were bringing up accessibility stories before. So, for example, we were discussing the you are more for color blind people, obviously it's not a new befriended task. But, yeah, these tasks as far as definitely make sense. So, my main question is how far we would like to go in general. So not this new befriended tasks, but what would be the end goal for us. So, and goals should be maybe making Jenkins legal to use in countries and places where you have, for example, in a government or in a big company should be able to use Jenkins without fear that somebody some employee would sue them for because the tool they are mandated to use is not accessible. So I think that's the extent we should avoid and I mean, this is a pragmatic way. And the target should be to serve better most users, but the more pragmatic and cynical is everybody should be she feel she'll feel safe to use Jenkins as a tool in these cases. Yeah. Now it's perfectly fine certification so it's important, especially for vendors, but for many users, it's, it may be also decision criteria. So we say that we comply with some standards and we have proof of that it would definitely help. Why I'm asking is mostly about because of the Jenkins roadmap, because accessibility looks to be a good item to put there in general. But if you want to put that we definitely need to somehow document this bigger story. Maybe it's an additional project for your xc for the future for now I don't know. But yeah, would be interested to put something like that on the Jenkins roadmap. Do we have identified a particular tool or test that we want to pass in order to detect those accessibility issues. I don't know. I don't know right now. Well, I have no idea how to handle accessibility. I mean, there are, there are lots of of browser extensions that you can install and we'll do an accessible first level accessibility audit of the page. But if you put them in Jenkins, they will just explode. I mean, and Jenkins has lots of problems. It's mostly about the best thing we can do as developers is inform us ourselves on what the pro common accessibility issues are, because it's more and I'm trying to fix them a bit baby because it I don't think it's possible or reasonable to say, and we are going to make Jenkins double a accessible in one year. I don't think that's feasible, especially considering that you need to spend so much on the plugins and plugins can be inaccessible themselves. And they would be maybe bring maybe the excessive the level of specific. But what can we do. We can create accessible widgets, accessible search bar and search works we can create accessible dropdowns. We can improve the forms the forms are a big one and thankfully with the new forms PR we are on our way to have more accessible forms. So, those are all places where we can help. I'm just keeping an eye on the clock here I don't want us to miss on on some other ones so we might need to move on to the next. Jenkins you you have some like hackathon proposal mark. I have to have a view do you want to share I have to hackathon. Yeah, I can speak about that. So if you don't mind I will just share my screen. Okay. Yeah. So we haven't really discussed it yet. The public and actually this is just a quick heads up. We were discussing having kind of online hackathon for a couple of months. We discussed it in Brussels at the Jenkins contributor summit. We had a number of hackathons before and they were quite successful. So for example, here we have Java 10 hackathon into Southern Dayton was one week online hackathon. Then we had October first last October first again was pretty good in terms of contributions we accumulated. We had more than 100 contributors to the Jenkins project coming through October first. And we had an interest to run something and after discussions we thought that it might be good to actually focus on user experience. Why because the Jenkins user experience is one of the biggest issues. And as Felix talked before there is a lot of various new befriending tickets we could create. So the idea you'd like to propose. Again, I will shout to the developer Malin please soon is having online hackathon for that late May. The reason why this time frame is because it's end of JSOC community bonding so that we don't ever flow up with this JSOC coding time frame and also students can also participate in the community if they're interested. But the idea would be to focus on user experience it includes some stories like Jenkins look and feel updates. So basically we took stories which are already on the roadmap which we discussed at the previous meetings. Okay, so here you can see there are stories like you are you look and feel user interface reward we didn't touch it of course here. And user experience is also on the list. I also tentatively added accessibility topic just before this meeting when I've seen the agenda because if you have really friendly tickets why not. Also, we have a number of documentation things we would like to improve so solution pages tutorials is what we were discussing that the documentation seek over past months because documentation could be improved. The documentation is also a significant factor for user experience overall. We could also put a dog's migration so it's basically migration from weekend the story, which is still there. And yeah item which is currently in works the Jenkins the way user story site that is a blog post staged by Alistar Tom. And we were thinking that just to get the stories and to run a one week event where we invite everybody to contribute. And as a result, we sent some Schwab and then federal to organize some online events like meetups for example developer meetups for Web UI development. Also some grant opening like we did for October first for example. One week hackathon. So we will meet the reviewers will meet all social media stuff. I think that advocacy and advocacy would be pretty interested to contribute there. Yes, that's what we want to organize. It's all in draft this document basically just started tomorrow we just put some brain dump. But it will be sent to the community soon. So that just would be to get your feedback whether you think it's important enough whether you would be interested to participate and provide your feedback. I think it's a super interesting idea. I think that this is, I have not been involved with a hackathon for Jenkins in the past. I know that they are a really great way of building community of reminding people why they love this project and, and so I'm excited about this, I would love to also talk more with you. After this, after this call just since we're running out of time well like about some of the topics you have in mind but, but this is very cool. From my side thanks very much for considering docs here as part of user experience I think that's intensely valuable and we could get a whole bunch of newbie friendly tasks that would go into that bucket. Excellent. So, yeah, hope to share this document by the end of the week. So, again, it's just a preview. Getting you a samples back into Jenkins core and have actual samples or buttons for example on icons. It would be amazing. Why not. So yeah, of course, it's online hackathon. Yeah. So everybody is welcome to participate. If you are concerned about timing Java 10 plus hackathon basically it was organized with two weeks at once. We have three weeks. So, yeah, I think it's technically possible. We will dedicate some time. We also discussed sponsorship. So we want to tie to Jenkins is the way campaign. Hence, we will get Jenkins in the week t-shirts for contributors. We are probably will be able to facilitate much work. These t-shirts are really nice by the way. So, yeah, more details soon. But yeah, thanks for letting me speak briefly about that. Awesome. Thanks for sharing for raising the issue. So, next item this piece. Okay, I'll share again. Screen. Community contributions. So Balek wants to raise the discussion of getting rid of jQuery prototype UI. Yeah, it just, it was a topic we started discussing in our internal Slack with Felix. So we got multiple security issue with this library because they are outdated. Most of them are not something that is exploitable in Jenkins, but we still get a lot of reports. Yeah, your application is vulnerable and things like that, even if it's not true. And the fact that we are using very, very old library seems to be weird, especially the Yahoo stuff because it's completely out of support. And the version we are using is not even the last version of the library or things like that. So it just a reminder there. If you have some ideas about how to remove completely them during the CSS rework or during the next phase or during the next next phase, it's just a very good thing. So share your ideas, share everything you can have with that. It could be just useful. Yeah, I want to, I will repeat here what I said, I want to be brief, what I said on the UX GitHub. I think jQuery is removable. I think if we want to remove prototype, not just from Jenkins, from the whole ecosystem, it will take one and a half to two years. And we at the deprecation notice we should give, because if we want to remove it, it's used all over the place. It's so connected to everything and it's really difficult to remove. So that said, if we are willing to just say we have two years until we remove this, it's maybe it's enough time for plugging the offers to consider it. Other than that, it's going to stay there forever. Yahoo UI does not concern me as much because Yahoo UI does not modify the JavaScript runtime, which prototype does. And just for the fun, we got a report recently from a customer about the Yahoo UI because of some inner HTML tag used inside that library. Burp, the software used for the different pen tests and things like that you can do on the web application, said it was a dumb XSS due to that. So it was confirmed that it was not a vulnerability, but it's still something that is outdated and potentially annoying for us. So for me, it's more a security concern. And if we can say in two years, we get rid of them, it's already a very good thing compared to the current situation. Yeah, I mean, that's not my goal. So I just want to make everyone aware of the severity of that. So that is going to take one year to remove or more and then count it another year for everybody, every planning to be up to date. I think those are the stakes. JQuery can be removed safely. Yahoo UI can protect not. It could be looked at on a component by component basis, at least in core and reduce the reliance on it. Yeah, I mean, definitely. Yeah, I've had the misfortune of touching it recently and it took me quite a while to get my head around it. Yeah, I agree with you there. And I would like to move to the next item if possible. So do we want to discuss any further? No, no, it's just a highlighter. If you have some ideas, if you're creating a new script and you are not using prototype, it's already a good thing. I'm just going vanilla JavaScript. Yeah. And no prototype, no jQuery, anything else. Yes, but vanilla JavaScript. And that's what I suggest. Okay, next item is not a priority. There are just two issues I detected with on current Jenkins, maybe some of the introduced with the typography, some introduced with the buttons change. So basically here these buttons in this pop up at least. Clicking help us look at this page. They don't have the right styles. I'm just working on a fix for that for this next print. I don't know if this is up. It doesn't hurt the case for the buttons to be LTS. But I mean, I have the fix located. And the other one is a fun. What plugin is that Felix I've never known how to get that link. It's the translation assistance plugin. Right now we have some issues with this plugin, because it has infrastructure. Which is supposed to receive the localization suggestions. So the button I contribute my translations to the Jenkins project basically doesn't work right now. But you can still do it for local editing. I have long standing action I can in my backlog, even not in the backlog in the future to release new version which improves the situation. But regarding these buttons, I wouldn't be concerned at all right now. Because this entire functionality needs to be updated or removed. Yeah, you want to do that. No, I saw it only I found another instance of this issue in only one plugin and I think it was. Here, I don't know, or in advance in one of these plugins. You have a skew of plugins. Never seen any of these. Yeah, I did lots of, I did some rather deep dive into this. But yeah, I think they are moving ahead. Boxes for alert on broadcast interaction. I think that's a PR by Roman. Yeah, that was just a quick note that Daniel realized that there was an issue with this one when the alert appeared and you were scrolling. You will not be able to click the breadcrumbs because the thief actually was there was visible and was displaying. So to Felix point, I first was trying to change to displaying on when the alert was gone, but that wouldn't work with the animation. So I just did a visibility change to make it disappear. Now the breadcrumbs should be clickable again. So if you just click in the files changed, it's a very easy fix. So that's, that's there. I mean, it's getting, it's getting merged tomorrow anyway. So, right. Yeah, so that was a quick update on that. Okay, thank you, Roman. And Mark, Mark, can you please comment on this item. Just a reminder to everyone we're at a precious time when the next long term support release is being selected. The hyperlink there takes you to the mailing list where that's being discussed. And Tim Jacob just barely shared his insights Daniel as well. Don't be shy about sharing your, your insights so that the community is aware of what you're thinking in terms of evolution. So, yeah, I wanted to ask about this because I, I don't, who's supposed to answer to this thread. I mean, people with right permissions to maintainers or everybody in the community is welcome to contribute. Right. Anyone and insights are valued here in terms of knowing where we are at in the evolution. I love but he's observation and I even more value Daniels in terms of, hey, to 235 looks very promising. It's okay in this process to choose and not yet delivered release because we've, we've changed the LTS process, specifically to allow that. I'm not specifically so why we discussed for this version because LTS decision date is next week. So we have one week to make a decision. And hence we can discuss unreleased version because it will be still release by the decision date. For me, for me, it's great, because it leaves us. I'd like to beat the buttons to be featured. And because it's in the more you I changes, especially the buttons that they are rather dramatic change. So that's my vote. And we, we still have time for all the fixes we want, because in two weeks is more than enough time I believe I don't want to jinx anything. So, but yeah. Okay, thank you. Thank you, Mark for the clarification I will I will also comment. So we have three days to stretch the definition of merging something crazy right. Please, please don't do the merge something crazy thing right that would be yeah. So no deeps, right. No, it's not going to get merged. Thank you. Thank you. We appreciate that sacrifice there. Unless you want to do around to burn the release. Okay. And when the, when the meeting I would like to call attention to the, to the PR of migrating forums from deeps, sorry, from tables to deeps. It's a big one. So, and it's a really, really big one. I'm really excited for that one. It's going to break stuff. Definitely. So we want so we are looking to have it merge as soon as early in the LTS cycle as possible. So I will know anybody to go ahead and try it out. I would phrase it as early in the next LTS cycle as possible, not the current LTS cycle that that would be that would be a burn the release just the way Tim said it. And yes, but next LTS cycle is in one week. No, but yeah, I mean, not, not next week, but we wanted to do it rather soon, as soon as it's reasonable. Okay. So any testing that anyone here or else we want to do would be great. Myself Felix and Joshua Gordon and Daniel have all done a fair bit of work on this. And it's going to get smoothed on a lot in the last few weeks. Yeah, I'll try to focus on smaller changes to get them into the weekly, especially system rent and other things. Yeah, I'm still in the end of quarter state. But yeah, I hope that I will be able to do it sometime tomorrow and on the weekend. That will be great. Okay, so is it, I think we are to you. It's been one hour. I think we should call it a day. Thank you everybody. This will be a rather productive meeting. And see you in two weeks. Who had record on this one. Sorry, who was recording this one. It's recording automatically Jeremy will dream it. Perfect. All right. Thanks everyone.