 I am going to go ahead and share my screen in like just a second, I promise it's coming. Maybe, yeah, maybe Josh could introduce himself and then we could introduce ourselves to Josh. Josh, this is your first time. And Amber is also her first time. Also, yeah, of course, yeah, I know Amber, but it's true. Most of you don't, so yeah, you can tell me right. Welcome back, Ryman. Okay, I'm Josh. Sorry, I'm trying to use a space which is well lit. Unfortunately, well it means that there's a sun somewhere out in the general area, and it kind of washes everything out. Can you hear me. Yeah. I currently work for small company and we use Jenkins in past lives I've worked for research in motion and Nokia. And before then I worked. Well, up through Nokia I was working on the missile project for various companies. So I've done various things for user interfaces at various places. I will slowly be taking over more of the actual user interface work for design work for our actual company project going forward probably, but I'm doing this work because basically I work to improve anything I touch and Jenkins is something that we're using so awesome. Welcome Josh. Amber, do you want to do a quick little intro and then, and then we'll run to the agenda. Amber I'm going to be managing the design team overseeing flow core Jenkins and accelerator so dropping into take a look at what's going on see I can help. And then as we usually do, make sure I'm not missing anybody. I think that's everybody might be new to the call. Somebody self may come home. And as we usually do we'll just kind of run through the agenda for today and then give folks a chance to add something if they want to. So a couple of quick updates on the list for today are very simple just a reminder of that new resource. We'll take a look at that when we get started. We'll take a look at a second or another second a new design deck this week with text link styles and a footer design. And then we have a discussion here about how to triage some, some open source tickets as well that Felix you could probably speak to a little better than I could right now. Is there anything anyone wants to add to the look today before we dig in. I'm going to ask for one quick thing. Somebody is joined as foundation team dot dot dot. Yeah, that is. That's funny because I was actually posting a comment right now. So hi, Jeff happy, Josh happy to actually meet you kind of, well, not in real life but to see each other. I'm back to some I've been contributing to Jenkins for a few years but not in many locations. So, yeah, happy to meet you. Awesome. All right, let's dig in. So the first thing on the agenda here is super simple. All the names will also be in the minutes. So I update minutes. If you need very interested in every body's names just read minutes when it's finished and find all the information hopefully cool. So first on the list here we've got this is a resource that was requested a couple meetings back. Essentially, for folks who could not make every meeting and you know we have one of these every other week. They wanted a way to kind of be able to scan design improvements and see what's going on without having to attend or maybe a conflict. So the first simple web page here all this does. It's again very very straightforward is gather up mocks from our different meetings, both directly out of our slides, and then these link back to the relevant slide from from or slide deck from that meeting. So this is sort of just a board to collect those all up and that's useful for some people so just a reminder that that is there. And the second thing we'll dig into is a design deck for this week. Actually, I already have it open here. Cool so it always kind of pet peeves me when people don't go full screen, because it's you know it's right there but I'm actually going to break my rule and not go full screen this time just anyone let me know if, if that's not big enough to see or like that. And because we have a couple of people on the call today who aren't normal attendees, or maybe interested in the initiative, I'm going to run through some of these slides that are usually here that we usually skip over when there's not a new person attending. I'll try to do this quickly so. So what is this right what are we've been looking at here. Of course this slide deck was created as a resource for the Jenkins UX SIG, which stands for Special Interest Group. We meet twice monthly and discuss ongoing Jenkins design projects and the long term future of Jenkins user experience. And what motivated the SIG and recent months was that cloudbies is working on a visual refresh of the Jenkins interface. And so the design team here is sharing details about each redesign component in these meetings. And this is part of our process, key part of our process where we gather feedback from the open source community from all of you. And that, as we have seen in recent meetings has a really big impact on how the designs unfold and on what we implement. We've gotten some great feedback we were in slack for a while we moved over to get her so that the conversation is more public. And it's been a really good back and forth for the past few months now. I won't read through everything here, but if you'd like more context about the visual refresh. What is this initiative. How does it relate to the Jenkins brand. Is this cloudbies taking over Jenkins the answer, definitely not. And how that all pans out is is here. And this slide deck and every other resource we have related to the SIG is all in one consolidated resource doc which I can reshare after this meeting. One more thing I'll mention here is this last tidbit about working toward a Jenkins design system. This is something that the community has tried to do in the past you know there have been there have been previous attempts to try and do this. It doesn't make it any less viable to try and make it work now. We're coming at this trying to involve all of the relevant parties and make sure that we're designing for what Jenkins is right it needs to be fundamentally extensible. It needs to be a community first Jenkins is a very special project and so we'd like to do this but we'd like to do this the right way and a small part of that is why we're here talking today in this format. So we'll jump into the first thing here and I feel like I'm kind of broadcasting just because I went through those early slides but of course anyone can interrupt me anytime and then we can talk freely throughout the call so the first thing we'll look at here is standardizing text to link styles. It might seem like a fairly trivial thing right now but you know text links in different forms are very common throughout Jenkins interface. And so what I want us to do here the intended outcome is to establish clear established clear interactive states for defypes of text links throughout Jenkins and improve clarity to support the way people use them now but also make them more intuitive for people who are coming to Jenkins maybe for the first time or relatively new some additional details here and we'll take a look at these in just a second. Thus far we've identified three distinct types of text links sidebar ephemeral content links and standalone links. We'll look at those in more detail in just a sec. And I want to highlight to the nature of this meeting is is never to say we have designed something or we have implemented something and it's done. Here's what we did. It's over nature of this meeting is we're working on XYZ and we'd love your feedback on it. So the stuff we look at here you know it's not set in stone. We of course need to maintain sort of a window for feedback but totally open to it. So just to point that out. Some more stuff here clearly defined link styles the way they improve the user experiences by communicating the type of content that they link to right so I mentioned links are everywhere throughout the interface right now. But if we can define some clear styles and and and help people over the long term associate different functionality and different types of content based on the styles links. That can make the overall experience a lot more intuitive, even though it doesn't look like a dramatic shift visually. Color treatments are based on the Jenkins color palette which we've looked at in the previous meeting. And of course just like any other component right. These explosions are going back and informing the evolution of that palette. So a tiny example being a visited state for link. This violet color wasn't per that wasn't previously in the palette so we're going back and adding that just like with any component or any elements. They feed off of each other and and make the system stronger over the long term. And just yet so just like I was saying there as with most other elements these will help inform the design of more complex components moving forward. Let's take into those three categories that I mentioned sidebar text links, ephemeral content and standalone. I think there's a couple comments let me just make sure of course anyone can just speak up I want to make sure I'm not missing. Yeah that's a great point Josh. We can link to get our on the agenda for sure. Awesome already done. Sweet so let's talk about these the sidebar text links. The link right is exclusively inside of that that left panel that sidebar we don't have a official designation for different people call it different things. But it's where most of our navigation occurs and it's where of course plugins can contribute navigation items and different links as well. So the treatment for those links is very much, you know, a work in progress on the design side right now, because we're also currently designing that that panel. So these will change quite a bit, but this kind of gives the idea that we're starting to think about what would be necessary for links in that panel. As far as different interactive states, some of these are already there, and some of them, maybe haven't been considered yet it's a mixed bag throughout the interface but this is something we're mindful of. The second type of link here would be what we're just calling ephemeral content text links. The links to content where it's especially useful to have a visited state, something that might exist in a long and a tall list of links, say, different different builds perhaps, and it's especially useful to go and see which ones you've clicked back into. In comparison, sidebar text links for top level navigation items, it's not useful to have a visited state in fact it can be sort of a detriment to the experience especially for new users to have that for something that's more high level. So this is stuff that, so this is stuff that won't necessarily be a link that's commonly available forever might not be referenced all that that frequently we're thinking about how to solve for that category. I'll go ahead. If I may elaborate the female category as well we familiarize the best name you came up with. It's mostly thought for stuff like job, a number of bills jobs on the first, when we first run these hyperlinks in cloud based on people told okay we want the specific styles for, for jobs we want to see what when a job was visited when a build was visited when an article was downloaded. So that's why we want the family of, of there is a family. Yeah, I know if I'm really saying good. We accept the better name. And we want what we want is a family of styles for stuff that would you a user would want to see that is necessarily not permanent or, or not a static. And the user can see that whether they have visited it or not. So that's the context for this dynamic links yeah dynamic dynamic maybe better. And we, I mean, just like, just like the, you know, whatever anything else we look at, totally change that so that makes more sense. Sure. Also, Josh, it's posting the judge by the way to raise things, or only because I'm not sure where he's watching the chat but you had a comment about text versus text link. Yeah, that's back probably around five slides in the, when you started talking about the sidebar. Yeah, so if you look at the top left for enabled sidebar text link. The real problem with the sidebar is that you also occasionally have things that are just pure text. And if you aren't keeping that in mind when deciding for the style of enabled text links, then you're missing what's actually important about how it's different from something it's different from text. So that needs to be visible and in conversation with text links. Yeah, I totally agree. And like, you know, I mentioned like this one, these are going to evolve pretty dramatically right because this is clearly as an enabled state not a finished solution, right this doesn't this doesn't look like text, like a link at all. So yeah point taken and that's definitely going to happen. I'm in general want to try and avoid using my voice because the more I use it the more likely I am the cost so my preference will be the chat. I'm currently using the version where chess merged to the right and there's a fairly large view screen and a couple videos on the top. It's working pretty well. No problem. I have a question about the visitor text. I mean, this is text links. I mean, I understand the concept of this to text in a normal kind of websites where it's informational but I mean how come I mean, is it to have a different style for this to links inside an application. Yeah, maybe it doesn't really make sense in my opinion for stuff like going through a sections navigation like that. But people, several people did mention that. That they think for stuff they want to see whenever they they went into a build they want to see what. Yeah, whenever they can see the locks consult the locks for a specific build. So it's for those those historic elements. I don't, I mean, seems to me that it's very weird or special case I mean, because for instance there's the latest links and those things which actually is pointing to something different over time so it's an application so it's not the websites. So yeah, I agree with Jeremy. I would actually be more like we shouldn't ever differentiate things but I mean I'm really really I'm really eager to read and hear from people who would like this to be a thing in Jenkins, you know, or keeping a thing. Yeah, I think to add my two cents there. I think the first time I use Jenkins and I saw the visited link state was weird to me as Baptista and Jeremy said, it feels like it's a website and an application so an application I don't expect to see a visited link. It really depends on the type of content just says in chat is for the logs and the history history elements is handy. Yeah, for me for me to visit the state is confusing, but mainly when when related to navigation. Anyway, I agree with you. It's very weird. But we are not considering it for navigation. We are both engineering it for navigation. I agree with you but this the Roman Jeremy, but some people did say that people did say that they missed that and they eat part of the workflow but and it's not not a weird but not part of a weird workflow. The time for a little picture you always share at this moment. Yeah, I was actually thinking about it like someone broke my workflow. Yeah, right. Nothing that regard. Yeah, but I mean, yeah, maybe I'm just thinking to address was just the same because it's maybe a subset of thing that makes sense might be making sense that we enable this only in big logs, you know, or whatever. But maybe nowhere else or something. But anyway, that's, yeah, that's, I mean, that's not a bad idea. I think we need to do a little more asking around and get or maybe other places to just to see how it and how it's a part of different people's workflows right because I don't think that even though I personally don't really like seeing them throughout the application either. You know, if they're if they're really important part and this one's actually not even that that's far as stretch to the imagination right like it's it's a useful thing, maybe not the most pretty thing but it can be pretty useful so that's an interesting idea though about this of maybe only in certain places where it's actually used. Accommodate people who might get used to that read that local place but I think in like like in the one sense. Central when you see the jobs when you see the base like the kind of local main panel or something. I mean, I mean click on the job. Yeah, I've already clicked on that job I've already visited it but I don't think I ever found that very handy. That's why people do using Jenkins we look into jobs and this makes no sense to be, you know, purple purple you know. Fair enough. Yeah, I mean, I'll raise it again and get her and like let's see if we can get more voices on it to just to see competing thoughts but yeah that's a good point. Sure. I mean we have many people here already I experienced a solution I mean team for instance you have an opinion about that or really because I mean you've been using Jenkins for a few years. European would be interested I guess interesting I guess. Yeah, sorry. I think I don't use these states really because I'm just clicking and then I want to open the new page and I don't interested in if I ever have visited that page previously. I use link from GitHub or search and yet not really interested. So for me it's okay to remove it the state. Okay. Okay, I'd say to to more asking see if more people feel that way or is just specific. That's an amount of people or maybe we can consider it not bringing it down only for the bills. So let's do more research on this one. Sounds good. We move to the next one. Yeah, for sure I want to I want to watch the time to so good call. This is a very straightforward one so I don't think we'll have as much to dig into. What we're calling because to my knowledge and it might have one somewhere in documentation but my knowledge and have a name before so we're calling the footer inside of Jenkins. So the goal here to delineate between current content that is in that space, using some subtle visual improvements, and then to introduce a little bit of graceful degradation on smaller screen sizes. I actually wanted to come with a specific question to the group and say, I want to get different people's opinions on the value of seeing those page generation details at the bottom there. Is that accessing or you want to go access on a smaller screen? Is that something that you'd be in the same one? Have any strong opinions about removing that? Is that something that's a party or workflow in some way? I'd love more insight there. I've never used it and wondered why it was there. Yeah. I mean, that's sort of what I would expect to hear honestly, same year but okay. Any other thoughts on that for now. Josh is sitting chat. Why would I want to know about page generation details. Exactly. I share that sentiment. One thing that is shown in the footer is the link to the remote API. This is very often used, I think. So if you do something here, you need to present it somewhere else. Yeah, you're totally right. Felix actually was pointing this out to me yesterday and I haven't gone back and updated Mox yet. But yes, that will have to be added in. Maybe we can hide the page generated on the new UI flag to see if somebody complains or maybe ask if somebody actually uses it. Because maybe somebody is half and half. Well, I was about to say auto-refresh, but not anymore. So then, yeah. It's a very, it gets very specific in its page generation details right down to the second, I think. So it's, I'm sure somebody uses it somehow. We'll look into a little further to see whether that's keeping around that sort of thing. Yeah, the last thing to look. I'll go ahead. I'm going to ask on the sick chat, maybe on the developers mailing list, because there are a few things that look like insertion points for JavaScript on the footer markup. And I'm going to ask in the developers mailing list probably on Friday to see if somebody is actually some plugin is actually using it because, yeah, in order to not break things. It's going to be used so that you can add your own links in there. I think there's a system property that you can set, and then you can set your company's URL or something as well. Yeah, I don't know. There's a food, there's an empty with ID, ID called food or within them in the middle. So it's weird. So sorry, Joe. Go ahead. Oh, no, you're fine. That's interesting. And in this we actually looked at in the last meeting talking about, you know, very ambitious goals for what we'd like to achieve and so I put this back in the slide back because I was anticipating what have some people who weren't here last time. We're at least, at least incrementally working on throughout the rest of this month and next month. And it's, you know, still sort of to be determined to what level of fidelity these will exist but throughout the past few meetings we have seen, you know, progress on each of each of these things in some small way. They all inform one of one another. So it's really not a very linear process of like header footer buttons typography, you know, we talked a lot about typography two weeks ago, for example. And that's further on the list technically. So anyway, I wanted to put that in there, but I don't think there's more to take into for the moment. And then I know we have a lot more topics still so I'll end this part here, providing feedback, the same usual conversation or the same usual slides. And I think we might be ready to move on to the next topic here. Yeah. Oh, this is contributors. So I'll let deep mention on the sick chat that one thing we discussed we on the past meeting was that we want to have more involvement from the community, especially because here are always we want to focus on the bigger stuff. So Joe does the designs validate the designs and work on the main line, but some stuff is kind of should be left to the community. Very well. So, what else. Yeah, by the way, Josh, I'm Felix, I'm the, I'm the front end developer who is who is working on this project on set of strategies. And in case I'm fk to that in. So these are, this is a list of issues that I've identified. They are part of the epic for on the Jenkins on the OSS issue tracker for for the this project. So I wanted to give a rundown for these items. So maybe we can check them, just to do a quick mention, I just wanted to introduce them to everybody. And to see from everybody. So, yeah, just to make everybody aware. So the first one is that they can you expand on the screenshot. Yeah. So yeah, the new applied banner looks not good. Daniel back reported this, I think. And yeah, it should be changed. I will probably mark this up as a new friendly. Yeah, I would be happy to, I commented in that one Felix, I would be happy to play with it maybe trying the bootstrap alerts or something like that. Yeah, I mean, bootstrap alerts. If you just want to copy and paste the code, we already we already have code for the bootstrap. We already have the bootstrap code within Jenkins. The alert alert dot dash danger all those classes. If they are in in in in, if not, you can just copy and paste the CSS from bootstrap on it's okay. Just go ahead. I just assigned it to yourself to yourself and work on the PR. I'm just asking the sick chat if you have any, any doubts regarding design or whatever. Okay. Thank you Roman. Next one. And then hey Roman so so something keep in mind to you know, all everything's kind of linked on the resources doc but when it comes to like a little individual design decisions and stuff like that we've got a palette we're trying to make this whole piece of long term right so like, reach out to me and let's let's work together on that too. We'll do. Okay, this is more of a toolchain one. This is something that if not, if not the body does it I will do in the future. So basically, toolchain enhancement that in both CSS, so that we can automatically add vendor prefixes for browser so that we don't worry about when do when developing CSS we don't worry about all worry about old browsers too much. So this is just another one. Can you. Yeah, not a really important one. I'm reading root breadcrumbs. So, Slaving Nunes and wants to work on this. So this is something that we talked a bit back in January I think that having the root breadcrumbs called a home is just doesn't feel right. They're called Jenkins so we were thinking about calling it home. I know some some project some teams want to customize it in some installations to say a different name in the in the root in the breadcrumbs root. So, Slaving Nunes asked to see if he can get started working on this. It's a shame he didn't join in this call. Can you scroll down. There's in the comments where I we discussed we discussed a bit about enhancing the breadcrumbs system. Right now, there is no There is no infrastructure in Jenkins to for programs. They are just there you read some stapler path someday they are generated there are no utilities you cannot check What what if the breadcrumbs is it corresponds to the current page if the breadcrumbs has a patent. So we cannot do good designs for mobile. That's also one of the problems. We don't have we cannot do mobile fallbacks for the breadcrumbs. So there's a proposal we there's a discussion there about improving improvements on the Java API. I just mentioned that maybe home is not okay maybe main. Ideally for me this is something that should be configured also so So yeah, I it would be great if somebody if you can you won't take a look discuss the Java API whatever. Okay, next item. So yeah, Josh, I saw that you reopened this great PR. I think it is for context. We want to work in the forums in the future to do to do actual designs working the inputs, input styles, label styles. All of that stuff right now is impossible, because they are the way that Jenkins build the form is using tables. So, yeah, this initiative is really important, at least the infrastructure maybe just having the infrastructure of being able to use deeps. This allows everybody to expand. Can you, can you do you want to talk about this a little bit, Josh, or would you rather not. Um, so. And yeah, this is I mean, first of all, I started working on this over a year ago so I, I don't even remember what I ran into but yeah I was probably on some sort of mobile streak, and the fact that Jenkins works so really poorly. Whereas, probably at the time I was starting to play with either Travis or one of the various other competitors. I'm basically a GitHub user, and that means that I'm randomly contributing to random projects that use random CIs. And every other one did a reasonable job of scaling to mobile, but when I was actually interacting with my companies Jenkins on my phone, it was pretty usable. So, this was an effort to, I think this was an effort to try and bite off the easier part, because there are thankfully not so many ways you can mess up the settings thing there's a there's essentially a theoretical toolbox that most people are using for it. But I figured well, we can try this. And if I can push this through then I can go after the bigger things which is all the actual UI things, although if I get this merge and if somebody else wants to take it forward to do all the more advanced or some UI things. I'd be quite happy to stick a victory flag and move on. Yeah, the general idea is that if you get close to narrow screens you end up having very basically vertical form. The picture at the bottom of the screen is a good example basically you have a title, and then an object and title on an object and says, that's mostly how mobile things work. And I was working at research and motion before that I was working at Nokia and actually I was at Nokia when Microsoft effectively bought the Nokia engineering group. So we were starting to use the Windows phone style and that was very much the style of basically you just had control and thing and it's actually a very usable model and mobile. I mean, it's, it's a lot harder to mess up than the models of letting developers try and pick everything. Because it's fairly forgiving. Everyone's just sees there's a thing in the thing and just like okay well obviously this talks to this and there's just not much else to do. So that that's basically the general design principle, the implementation is basically convert everything from tables to forms, or sorry, from tables to divs deal with a lot of fallout and then answer questions of for instance where we put the question marks. The question marks took a little bit of time. Because on mobile it's totally fine to have the question marks flush right. There was fairly strong feedback saying that if your screen is as wide as the screen in that you're sharing that having the question marks on the far right of the screen and the actual label on the far left of the screen. And if you have a bunch of them next to each other. It's impossible to get which one is talking. If somebody wants to we could set it up so that the question marks on mobile do one thing and on desk or do one thing on desk up to another. I'm not opposed to that, but I'd rather land the feature in general and have somebody else move that forward. Again, this feature has taken a year of clock time. Not technically your engineering time, I've done it in bursts. Mostly spent in various states of either test fails or merge fails. But yeah, so at this point, I believe it's still in the test of failed and I don't have a lot of patients for it. Currently, my team has an on GDP database which is corrupting itself periodically, roughly weekly in fact it's scheduled to trap itself today. So I'm here for this call because I need to be because I want to move this forward. I'd like to get some official go for it let's push this in. But that's about it. I really don't have time to make the test work. If somebody else could give me a hand that would be great. I don't understand the Jenkins tests, and I'm not particularly a fan of them, because basically whenever I try and make any kind of change I generally spend more time fixing tests which I generally find to not be particularly great. Now I'm generally a critic of everything and you'll see that I'm giving feedback on everything as people run here in random projects about everything I just, but I don't have a lot of time. But again, my official I has it. I'm going to have a database that I expect to corrupt itself within the next five hours. So that's an overview. Yeah, well I cannot talk for the test. I just want to say that this is a great initiative. I think it's really important. This is a problematic because it's really, it's really sensitive to to merge conflicts. Basically everything goes into a merge conflict with this PR. What I would think it would help us. I did try to dig into this PR really understand it so something I don't really get the picture is where is it now. So, what, what are the limitations, what is there. So what extent is done to see how did you end up having a strategy for improving the plugins. For me, my, my thought is that we should leverage the F entry or whatever new F entry v2 getting help as much as possible so that we can update it and the plug is with update update themselves. But yeah, I don't know exactly where this is at the moment. So, to be honest, I've only done merge conflicts, just so I can be here and talk about it. But the, I was for a lot of the things that I've gotten stuck. It's because I'm essentially looking for feedback. Basically there were a couple paths forward. I didn't really have one that was that seemed people were actually actively encouraging. Like, with the question mark people really cited on something so it's like okay I can go that way and just do it. But for which way to go, whether one or the other, there just wasn't enough anybody. The only thing that actually did get done was, I think I got the hetero thing fixed so that it will be able to work once we switch. And so that cleared somewhere, I think in like September. And I, the LTS bits for also cleared so at this point, that's no longer a stumbling block, but I haven't actually even run this locally so I don't, but it sounds like you actually tried using it. So it sounds like it's not totally broken. I ran it yesterday. Yeah, right somebody shows the pictures and GitHub so I'm, yeah, that's me. Sorry. Thank you. The way zoom is using is showing pictures it's just a static set and Tim is on next screen, which is unhelpful for me. But basically I sent PRs to a bunch of the plugins I ran I have a profile with, I think a couple hundred plugins which I occasionally play with. I think Daniel Beck gave me a list of plugins at one point to look for because he ran a script to try and figure out which ones were likely to break. And I did use that to try and identify things. There are some which I fully expect to break. I think data dog might have been one of them, but this was from like probably nine months ago. And maybe like one of the AWS plugins. So, I mean, the general idea for this should be to land right after an LTS branches out, I think, so that there's the most amount of time to break all the interesting things and then spend time fixing them. So, because there's no real way, what I ran to is there's really no real way and you can see this by the open PRs for the other plugins to convince people that they actually have to make this change until you say well this is live you have to make this change. Yeah. Yeah, for maybe that really. Sorry, quick question what's the level of effort for the plugin signers to move to this. Sorry, who was speaking. I was wondering what level of effort is for plugin owner maintenance of this new system. It's not a huge amount of work. In this case it is literally changing the word table to the word div and the word TR to the word div and where TD to the word div maybe adding some classes that are like TD or similar. The amount of effort is a little bit higher if you were actually doing fancy JavaScript to muck around with things. So the fancier plugins were making some extra odd copies or doing some really odd things with the work. For them it'll be a bit more work, but as long as you have somebody who understands it as opposed to having a plugin that's 10 years old. The odd to somebody having an Ajax plugin that's 10 years old that's doing that stuff is I imagine fairly low. But I mean, for like really, I mean, there's lots of plugins that are like not maintained. And you're saying every single plugin that has configuration will need to be updated. No, only the plugins that are actively used that have been written to use tables, which is most of them do not use tables at all. So it's probably under 5% of the plugins. You just use sand, jelly, then you'll be fine. Okay. I think something, so my thoughts on this is that forms are a problem. Forms are not usable in Jenkins. And there is no good, there are no good primitives in Jenkins to allow to not offer developers enough to for them to have a good options when dealing with with with forms. Also, but for me forms do need to work. And this is a necessary step. Because right now it's, it's unsuitable. I did try the table is just not possible. So I think we should maybe try to go ahead with this, maybe in the future. We can try to support you. If not, we can try to inherit this PR. But this will not happen within the next month. Probably. So, because right now we want to follow our roadmap. But we, we keep this PR open, we do keep our own this PR. If there's a blocker, we will, that we can solve, we maybe we can take a look at that. So yeah, may. There's also for plugin developers who are stuck there is a solution if they're actually doing something sufficiently complicated. They create an extra page that's not in the configuration thing itself. It's a standalone page. And they do the work there, and it'll be fine because this will not impact them. And in fact, if they're doing something that complicated, they should be doing that in the first place. And actually between why started this work and now or a couple months ago, somebody actually broke something out of config. It might have been like, like the VM cluster providers like AWS and things. Yeah, cloud configuration. Yeah, cloud configuration. Thank you, yes. So basically if you're doing something very complicated, kick yourself out of config, you don't get impacted by this and you get more time, and we'll visit you later. So yeah, that's, if people can't deal with it, then, yeah, that's the other way out. I'll try to take a look at this. So I had a bit of a play with it last night and it worked with everything I had installed it worked fine. It was just the issue with the padding. So the padding on the help icons and the form was too close. This test day failures I can take a look though. Yeah, I'm quite happy to set people up so that they can contribute directly into my brand into my repository so they can just add extra commits to muck with the paddings and styles. I mean, I don't care about mobile. I'm not at times on a pixel pusher, but on this one right now. And in fact, on some of the other Jenkins things I've done recently, I don't care about pixels I just want it just it's proof of concept somebody else to the pixeling to whatever they want. I'll try to take a look. Yeah, thanks. I'll probably take a look too. So my goal here would be to get these ready to get these functionally done not trying to make it prettier. We can do that's our future iteration. Maybe even. Yeah. Okay. Thank you, Josh. I think this is a really interesting PR really interesting one. Okay. Yeah. Jeremy. I lost somebody but thank you. Did you, I saw just you put something. Did you remove something. No, I did not remove something. I saw something about. Okay. Okay. Yeah. Okay. I don't, is there anything else we want to talk about. I don't know anything else for the meeting, but anyone else. Okay, let's all manually test the table to the PR. Let's try and get it merged into master next 12 minutes. No, I think what Josh said that landed after a LTS is smart. I wouldn't do it after this one maybe I don't know if if there is time to merge after. I don't know if Josh has comments about let's merge it to the safest point possible. Don't worry about merging when it says, you know, it's, it's kind of a downstream thing. We merge when we merge and it lands in weeklies, I think, and then, you know, the new baseline gets picked where depending on the various feedback we got, you know, so I don't think we should really worry about the weeklies are designed for this. It gets into an LTS plug and maintainers will fix it faster too. Anyway, we have that a public blog entry from Kosuke like one year or something ago where this has been kind of committed to be able to kind of try to accelerate or something. We need to find a balance between breaking all plugins and keeping Jenkins relevant all the time. It's hard, but yeah, committing to make plugins that have been released like seven years ago is obviously maybe an endeavor we shouldn't spend so much time on, right? So thank you everyone for your time today. Reminder we have a space or a channel like that's over in Gitter. And if anyone needs access, I think actually it should be publicly linked to everyone who attended today. I'll send the resources doc out after this. And I think that's it for this room. And we'll see you all in a couple of weeks. Tim added the link to the top of the minute. Oh, great. Perfect. Thanks for anybody watching that. It's normally every two weeks. Yeah. Is it worth adding it to the event invite on the event calendar? Yeah, that's a good one. Yeah, I'll do the same time that one. Cool. Thanks everyone. Thanks. Thank you. Bye. Good to see you. Thank you. Thanks everybody. Bye.