 Okay, I will start sharing my screen then, okay, everybody can see my screen, right? Yes. Okay. So today, we are going to talk about, we are going to talk about the new resource that Joe provided to share the mocks and the designs. This is based on something that the community asked on the last meeting. So then we are going to share what we want to do. We have a more clear plan of what we want to achieve within the next two months. We want to iterate and we will share some details about that. And then I'm going to present some typography changes. It's a proposal. Some of you may have already seen those in the Gitter channel. And then Uli is going to raise a question regarding the incompatibility of Jenkins of the Jenkins grid system with the bootstrap grid system and what can be done to address that issue. And then we will end up talking about what to do with the, about the Slack channel and discussions. And this is going to be Joe. So, participants and their interests, I think only, I think we only have a new person. Hi, Roman Rodriguez Hill. So, well, I'm Felix, I'm the front end developer here at Cloud is that I'm participating in this in the development of the new, the new GUI. So, can you introduce yourself. Yeah. So I'm Roman Rodriguez Hill I'm part of training team at cloud bees. As, as, but this said, I'm the guy from the Canary Islands. Last year I was trying to spend some time contributing to Jenkins I made a few commits to Jenkins core and publish a few blog posts. And in previous jobs I've been working as an engineer in the front end teams. So I really wanted to, I really liked front end and UX. So I wanted to try to contribute to what you guys are doing, which I think is great. Welcome. We appreciate having as many people as possible here. I think we all know each other, all the other people we all know each other so maybe we can move on to the updates part. So, Joe, can you talk about this. Yeah, absolutely. If you want to just open up that link. Yeah, sure. Very straightforward resource. I actually unfortunately miss less sick meeting but I went back and watch the recording and something that I was getting from the conversation was, you know, it can be challenging to, because it's a very specific time and we're all in different systems, it can be challenging to make every single meeting, which is totally fair. Now we do have everything, the output the notes the agenda and the decks from every meeting sort of documented in one resources Google Doc, but there was a request for having everything sort of consolidated as far as design mocks in one place. So this is a very simple web page, where the intent is going to be for every sick meeting, anytime there's a new design related mock shared that graphic will go up here in the stream. And each one is linked back to its slide deck to its respective slide deck where it was shared. So that you can get more context for the design logic behind these mock ups. So, this is hopefully kind of serving that need and I don't know I think, I think what I can Daniel I'm not sure if Daniel's on we're kind of requesting this. Does this sort of suit the need that you were describing what it I would love your take on it. I didn't look at the thing yet, but it seems interesting yet. It's super simple. Like I said it's just kind of bringing everything into one place visually, and hopefully that's kind of helpful for when you can't make meetings and stuff like that. But we can of course update this if needed. Maybe we'll just ping Oleg on that one or something, providing the link. I think it's great, because I think Oleg was actually one of one person requesting, you know, having like, I mean, I'm not saying that I didn't but just saying that I do remember Oleg asking for like a more like global thing, not just like the header work, you know, like, you know, what's kind of the target even if you see things are going to be, you know, adjusting, adjusted as we're going discovering the technical limitations or whatever so yeah. Yeah, there's always sort of a balance with stuff like this because yes everything sort of been documented up until now but it can also be really valuable to see it all to see it visually in one place consolidated so I totally get that. You know, at the same time I have to make sure that we're spending time working on this and rather not not getting too caught up in the process of documenting it, but let's let's use this moving forward and totally iterate and we'll see what Oleg. Can you zoom slightly I mean for the recording I guess it would be interesting for people to quickly have a glimpse on that even if we will provide the link to those things for people I guess. I actually already added the link to this web page to the resources Google Doc so there's nothing new on here today, this is just all the mocks we've, we've seen in the past couple weeks so. And that's it for that bullet point unless anyone has any other thoughts on it. Co is just a kind of free hosting class or is there something that you own off. It's it's sort of a very simple one stop shop host a one page website kind of solution, it's nothing fancy. I wonder if we should. I don't remember exactly how it's set up on Jenkins as I owe, but we should bring make sure that the UX Sieg page like he's either has these directly or you know points to the right things and it's fun findable from there. I didn't check. I couldn't do an action item to make it link to the UX Sieg card I have from the Sieg page. Cool. I think long term. This is something we probably would like would want to consolidate all of these a little bit better because there's a lot of stuff floating around but in the in the short term hopefully this improves it and then yeah we'll link it back to the website there that'd be good. Okay, great. Thank you. Thank you. Yeah, moving on to the typography changes. So, I know every goes okay then and that is you again Joe. Okay, cool. So, just for a bit of context Roman so this link to the slide deck will be available of course on the resources doc. So you might want to go in for for greater context about what this is and what we're trying to achieve with it. The first few slides in this deck and every deck are always the same and they, they might be good reading for you. But yeah, if you could go up one slide Felix. Okay, wait a second. Number five. It starts here. Okay. Yeah. So this is the new content. So Felix mentioned that we wanted to know that we had to find sort of a more specific strategy and goals for these next couple of months. For example, so if we think back to a couple sick meetings ago, something that I said was was coming up next, in addition to typography was designing the redesigning the admin monitor warnings. Now these are something that do that does need to be redesigned. However, in looking at the timeline and sort of how long it took us to implement to design and implement the header bar and we're still refining this this process of getting feedback from everyone and and implementing all of these designs so you know it takes some time and we kind of did a little bit of a reevaluation to see how we can have the maximum impact over these next couple of months. So what we did is we chose some some selective improvements for that maximum impact. So by focusing on base styles and some of the more common components. We want to be able to deliver small iterative improvements across many different types of screens right. And then I mentioned here that selecting that we've selected these because the challenges that will that will solve in designing and implementing these particular elements will help inform more complex and critical components in the future months. And then hopefully we can also mitigate some risk here right so changing typography is no small task but we but but it's more reasonable to try and solve typography than to try and solve the entire well let's just say to try and solve something that leans heavily on typography without thinking about type first like table styles for example. So we're focusing on base styles here. If you go to the very next slide. And here's sort of a visual of what we'd like to to fix over the next couple of months. So we've already of course got her bar with breadcrumbs. The footer is very straightforward buttons are probably not quite as straightforward but fairly reasonably fairly reasonable to get done. Right now there's quite a bit of disparity and button styles throughout the Jenkins user experience so like to consolidate that and improve those across the board. Felix will share in a moment we're already working on some typography improvements. And then a big one is that nav sidebar on the left side of the interface there would be a huge win. And then also sprucing up some remaining iconography. This is what we'd like to achieve over the course of March and April. So it's fairly ambitious when you think about the timeline and some of the technical constraints that we're probably going to run up against. But I think that's a good thing. And this is what we would like to get done this will really help inform more complex problems in the coming months. So any thoughts on that before we go to the next slide. Do you have a link to this deck so I can put it into my notes? Yeah, so I will add this one to the resources Google. Just like every other deck. So I'll put it there after this call just so we don't interrupt. Can you just post the link into the chat? Sure. I would like to elaborate on what you just said, Joe. Go for it. One of the things that we realize and this is a concern that Oleg shared with us is that we were too small and too slow iterating on the header and everything. And we want to be more agile. We want to deliver faster. We want to basically be able to iterate more and get a faster velocity, right? So one of our goals for dividing the work like this was to try to find work that can be done in parallel. Not just one waterfall model one now big header changes and one big type of changes in big changes now. For example, footer patterns can be done in parallel. We will probably have sometimes many peer many open PRs. We will also probably be separating within, for example, we will not probably land the sidebar at once. We'll probably try to iterate on it, try to get smaller changes accepted first and then expand on those. And the reason for that is, I think it's easier to promote to gather community feedback and discussions. But if you were framing with framing the discussions within a bigger picture, I think if having a smaller PR can help with that. So that's what we wanted to try this next two months. And that's something what I'm going to elaborate again. So that's sort of our plan. Any thoughts on this. Sounds much better to me. Great. Great. My thought is that you expressed it much better than I did Felix. So thank you. Okay. Yeah, everybody will be able to see this later. Yeah, so yeah, that's one of the, well, the state of the current buttons and why we wanted to tackle them. Yeah. That's a bit old. So, thank you, Joe. I'm going to move on to the typography changes. So, I'm building basing on what we just talked about, regarding typography. I worked in this past two weeks is basically taking a look at the way the typography code is set up, looking on how we can change it looking to how the typography behaves in Jenkins, doing some market research, so to speak. See what other similar tools use the typography. What I prepared was a really small as a small PR, sorry, PR candidate as possible. We did some basic typography changes that will enable us to do iterate more basically based on what we talked about last week meeting, we want to have typography changes that are go into the base styles of Jenkins. We don't need to update each plugin that we just want some reasonable defaults, but if you, but if you, you raise this issue for last, last meeting. So, yeah, so what we want to do is basically land this small PR first and then try to see maybe we can work in the hyperlinks maybe we can look if we can improve the typography in the plugins table maybe we can look. But first we want to have these base typography changes. So there, if it's okay, this PR will probably land this week. Okay, so identify stakeholders. This is something that we also raised a topic that also came up in the past meeting that maybe we can it would be good to identify stakeholders for each UI feature or each UI domain, for example, providing the admin monitors the great to have some security people involved. So, I want to throw the question out there, is this anybody feel that I know any specific stakeholders for for typography. Ideally, I would like to gather some feedback from everybody who uses from different screen sizes, different zoom levels in monitors, all that stuff, even especially, for example, if people have trouble reading certain fonts, or certain stuff. So, all that feedback would be appreciated. So if somebody wants to say, okay, I, I, this is my use case. This is what I feel about this. So, and they are welcome. Yeah, and now to gather some feedback. So, today I raised in the seed channel. I raised a pretty puts together a quick deck showing the typography changes. I also published a local container with them. Wait a second, please. Okay, so first of all, what did I found? I am what I found is that the Jenkins UI code uses different levels of font sizes from 13 from 10 to 11 to 13 to 14, some screens uses 15. It really varies a lot. But it's really inconsistent. Also, the fonts are, I believe they found they were too packed. Yeah, so the readability was not the best one in some screens. So, and also the font. So this is regarding font sizes, right? Also regarding font, the types even use the, the Yankees project, you, it was using Roboto and the Roboto font. And it was in most of the code ways it was using Helvetica, Arial, and other similar fonts, right? Is anybody writing in the chat? Please tell me if somebody is. Okay. It's no, it's other stuff, I think. I'm actually answering questions from a Roman, but anyone's, you know, outside can feel free because I'm trying to provide basically lending information for people who are willing to understand where we are. It's hard to present to keep up the chat at the same time though. So if somebody does have a question to the present to just ask it straight out, I'd say. Yeah, please, please do tell because I'm not looking at the chat. I'm not able to look at the chat. So, yeah, so move to a topic of fonts on the type systems. Yankees project is using some rather old and ugly looking defaults. For example, on Windows and Linux, it's using Arial font, which is not the greatest looking one, the best looking one. So this is what I found out there was. So we took some decisions. This is basically a proposal. So the first part of our proposal is moved towards using system fonts. Historically, people used to add custom fonts for two reasons. People added custom fonts to their websites because either because the default fonts were too big or they want a specific font to reflect a specific design. Sorry, not to be too ugly. So lately, though, in the modern operating systems, both desktop and mobile, you offer a good rate of decent, decent looking fonts. And basically the trend in the industry is use system fonts whenever possible. Right. And I did examine similar tools like it happened with other tools and everybody basically everybody's using system fonts and there's a big case for them. Users are familiar with them. It does not look off with the operating system of the users. They also save load time, for example, on a normal Jenkins page. And the robot, the font was 20% of the server traffic generated by the, well, what you don't have the front end payload was the font, 20%. Right. So definitely helps there. Yeah, so there are drawbacks. The first drawback is that the UIs can be the sizing of the some elements that depend on the font can be everything consistent from one operating system to another. And then the, well, yeah, that's basically it. That's the biggest drawback, but I think, yeah, I think basically this is the current trend in the industry. There are good reasons to try this. And I will show you how it looks in after this in Ubuntu and OS X. Yeah, so does anybody want to say something about this font system proposal, change proposal or something? I would like to say. What? Sorry, Jeremy? I said I would like to see it. I mean, if you can show the demo. Yeah, well, yeah, sure. After this, I will have next slide. So let me talk quickly about the text font sizes we chose. And we basically my research show that most of the tools of similar tools were using a 14 pixels font size with a line height of 1.5. Sorry, it would hear 1.6, but it's 1.5. Basically it's what everybody was using and for a reason it's a decent font size that allowed showing a decent amount of information on a screen with the same line height. It gives enough room to breathe the user. So basically what this PR will propose unifying all the font sizes, except on the setup we saw by the way. But to font system based on 14 pixel font size and then for smaller parts use 12 pixels and for bigger parts, for bigger bits, maybe use 16 pixels. Headings, yeah, we also changed headings, but those changes for the headings are not final at all. So yeah, these changes what you are about to see at a proposal, you can change and these are meant as a first step and not as an end goal, okay. So basically, I'm going to show some examples. This is on our sex on my laptop, on my MacBook Pro. This is what was the old landing page of Jenkins with the old typography. I think maybe if it was Helvetica being used. And this is with a new font. So the changes from here to here. You can see the disposition of the dimensions of some stuff definitely changes. So on the system, the different monitor resolution on a full HD monitor as you can see the phone does look different. It does look more in line with the native operating operating system in the system font. No, no, the system font is Seagull UI. It's quite good looking to think for my taste. Okay, this is the job screen. The phone watching Jeremy was asking if I windows the font was comic. So, yeah, I guess it depends actually could be, you know, because it's by definition the system font so well. Yeah, but it's funny if it was, we can do a theme for that. You can make a try to see how it looks in April. And advocate for that to be fairly low on the priority list of the comics. I will create this in 20 days, you know. Yeah. Okay. And yeah, so this is the job summary screen on the old screen. So and this is on the new sex. Keep in mind that I know this there is more white space under the header, but this is because the header heading dimensions change. But for example, I like the permalinks change. It's definitely a bit. I think they are more readable. They are less packed together. Yeah, yeah. Looks a bit easier. Also please notice that, yeah, that I took the font size down a bit from 13 pixels to 12 pixels on the side panels. Because I know we have had problems of feeding stuff within those panels. There are some, there's lots of open issues of all the time. So that's why I proposed that size. We can always forvert it of course. Okay, so I did what it would. Yes, sorry, Joe. Oh, sorry. Sorry, Felix, I just want to point out to like, it's a great reason to go this route because it's become the industry standard as you've described it as you were researching. But it's also, if we think about it, it's a sort of an opportunity to benefit from all of the investigation and research that several large, large companies have done to see what's best for users on their system. And I think there's a lot of value in allowing users to not jump into a different approach to typography and different fonts just when they're in Jenkins. But I think overall this can be really good for just user consistency in the larger Jenkins experience and in the larger CloudBees experience as well. No, anyway, go on. Okay. So basically this is a, this is a, this is a big one. I know this is this one is going to raise lots of discussions. This is in a forum. This was the old screen, the old type system and this is on the new ones. As you can see, there's more better article spacing within the elements. For me, at least it's more readable, but maybe some people will have a problem with having less information available on the screen. This is what it looks like and it would look like in Ubuntu. And then, for example, the security panel, the security configuration. This is what looks right now on the current font system. And this is what we will be looking on the new one. Again, more vertical breathing room. And then to be, to not be annoying. This is what it would look on the plugin table, more readable basically. So yeah, this is a, this was just a some iteration of the typography. This is something that I'm going to probably create a PR within this week. Before the end of the week. We would appreciate all the feedback and we can gather on this one. It's not meant as a, it's meant as a stepping stone. Okay. It's not meant to send all future improvements would be appreciated and we can, we hope to deliver then quickly in our PR. So please ensure everybody has thoughts on this. We share them. Can you drop a link to the presentation in the chat please and I'll put it in the minute. It's on the agenda, but Okay, and I will push it out. In the chat, I think. I think he's, he has the meeting. Oh yeah, it was two different decks, but yeah, no problem. It's in there, but also drop a link one sec. Okay. So yeah, especially Uli, team, Vadek, any thoughts on this? I mean, I've gone, I've gone through it quite a lot. It's good. It's kind of, it's quite hard to tell the change. You've got to flick around a lot. It's pretty similar. It's not, it's no major. I found a few issues which I've told Felix about on GEDA. It's more visible when you actually use it, I think. Yeah. In the screenshots, it doesn't retain so much attention, but when you are using it, it's, it feels like something's different. Yeah, I agree. That's, that's where it really comes into place when you're in it. And also, you know, over over the periods of time as we integrate other CSS improvements. This will, these improvements will compound and it won't just, you know, they'll complement the other things that were, that were improving. So overall, we'll create a better experience. Yeah, definitely screenshots don't really do this one justice. You really got to click around and see it. Yeah, I think it's, you know, I see it as kind of a foundational change that we need to build upon, you know, and it would be more visible when we like see the difference between say, you know, the weekly from four weeks ago. And the weekly from, you know, we eight weeks or 12 weeks from now, you know, in the future. And, you know, we need to basically lend it as soon as possible so that we can, you know, address the feedback, how like, you know, the fields. So, you know, we got address every single plug-in that would be doing weird things. So it's, I think it's very interesting. And we need to, as kind of a reading back on what you were talking about Felix about the velocity. I think we need to lend it and move to the next item and see, you know, what's the potential fallout. We won't be able to address any, you know, probable problems here. We need to lend it and move on. Yeah, especially because there are some risks. For example, I want to see the monospace funds look smaller or certainly on certain components. So I want to see, depending on, I will use one technique or another to set the font size for monospace funds. But I want to try to see it with actual plugins. With plugins that actually do change it. So I think that's what would be good having the actual changes out there. Right. This is, this is what we've come to realize in the software world, you know, that when people talk about betas and release candidates, nobody cares until it's actually released and then people start providing feedback. So I guess we should actually push into the weekly and see what people have to say, you know. Yeah. Yeah. Yeah, just show it. Okay. Great. The font size on the, the ones where you type your script on someone and not first. Okay. Any more thoughts on this before we move on? Okay. I think overall it looks good. I mean, I like it. I mean, but I think the main feedback is obviously we need to test this well in proper setups, you know. Yeah, definitely have hundreds of items rather than just a few. But I mean, I think the overall direction I'm happy with this person. Great. Hopefully we will get merged it soon. Yeah. Okay. Okay. Next point. Uli, can you please introduce us to what your proposal. Maybe you can you click on the bootstrap link for instance. Yeah. Maybe if you can provide some context and scroll a little bit down a little bit until the images coming. Okay, there are images. Yeah, this one. Okay. So I released this week, a new version of the warnings plugin. I have one thing I made in this release was a refactoring of all the UI components that I'm using. These are now bundled plug ins. So everybody else can use this plug ins as well. What I'm using is bootstrap font asum and some additional tools. And one thing which is incompatible with the current Jenkins is bootstrap for I'm using because in Jenkins we are using quite old version of bootstrap from to 14. I'm using bootstrap 3 and currently bootstrap 5 is in development. So I think, yeah, this is something we need to change. Because most of the modern JavaScript in libraries expect some recent versions of bootstrap, for instance. We wanted to use tables and some bootstrap grids. And these seem to be not compatible with Jenkins because we are using a quite old grid. And this grid is as you see on this image here. This is where I'm using this grid. This is the grid I'm using. And this is the official bootstrap for grid. But in Jenkins we are using an old version. And I discussed it already. I think two meetings ago. I'm not sure if it's a good idea to use this grid only in my plug ins. I think it would be better if Jenkins would use a more up to date version of the grid. So the idea is that I prepare a pull request in Jenkins that will replace the old Jenkins grid with the new one that I'm using here in this screenshot. And yeah, this will, of course, break some plug ins, I think. So one thing is, yeah, leave the old grid forever. And the problem is that we not only use an old grid, we use a patched version of that grid that has not 12 columns as the default, they have 24 columns. So my plan is, yeah, to replace that grid. And I created an issue for that. You find it in the agenda. And the idea is if you have some ideas around that issue, please comment in that issue. So we can discuss that topic before I'm creating a pull request. Yeah, I think it's a great idea. Also using the Wolfster grid is free documentation. It also has more utilities for, for example, spacing stuff where no more using an anti paragraph to add some vertical spacing. Yeah, my only concern is we would, what I would suggest is try to do some research to see what plugins would actually be with the actual impact on plugins would be. So basically have a list of those. It involves some grab, grab magic. Yeah, already grabbed in a GitHub. And there are not so many, which actually use columns, because actually we don't have much plug in that use UI, at least open sourced ones. I don't know what you have in a cloud piece. But I think it's a change similar to your changes to the food or or header. Yeah, there will be some things which will which look weird. But yeah, we can fix it so. Yeah, would be good if we can take that effort. Yeah, definitely. So any anybody else has any thoughts on this on the monitor. Okay, so what I would suggest to me is maybe we can, if we can get a proper list of the plugins maybe we can create a list of the plugins priority prioritized by used use. So just to see what the impact is, you know, see if there are 50,000 use plugins versus 1000 use number of uses, you know. But yeah, and if these changes we include this we will do our job with our proprietary plugins, of course. Dumb question from a new UX UI, actually expert. Sorry if you said it, Uli, but I mean, yeah, if we move to from from bootstrap three to bootstrap forever where we're going, we're going to break the world, right. We break some layouts. Yes. So I mean, like, is this I mean on the UI development ecosystem. What's the kind of a story here is this like our, you know, is it like the community is moving away from our, you know, other communities moving away from bootstrap three and you know, upgrading everybody's going to bootstrap four, or is this like Python, and nobody cares about Python three was now it's okay. But, you know, it's like a fork and people keep using the old version of bootstrap. Or you know, I mean, by that I mean, should we also kind of upgrade the Jenkins ecosystem to bootstrap four because that's the way to go for instance, you know, I hope I'm kind of clear. Yeah, actually, in Jenkins, we don't use very much from bootstrap. It's just the grid we are using currently. Yeah, right. So this is a small change, I think. But this is something we need to discuss in more general, I think which part of your IA libraries we should have in Jenkins so currently we have actually nothing. Now, I have for the plug in some more libraries, but this is some kind of architectural thinking we need to do for Jenkins, what should be part of core and what not. As far as I remember Jenkins core cannot use plugins to visualize things. So, if we want to use bootstrap four in core it must be part of core and not in a plug in. Well, according to that, for example, yeah, one thing is definitely Jenkins needs to provide a grid, because plugins need a grid, basically. Other elements you can put, whatever you want, and you can use that but the grid is definitely a problem. And by the way, you can name a space. Great Jenkins utilities, for example, instead of a dot Jenkins dash card or whatever you want, but you do need a grid system. And the current one is not standard and not extensible, basically. And that's the problem. It conflicts now with your plugins, but I'm sure it will conflict with other ones. And the problem with this is probably going to play is that, yeah, basically things will look off. And it's not about also using bootstrap within Jenkins, in my opinion, the way I see it, it's not about using bootstrap within Jenkins, it's that just adding bootstrap will break everything, basically. Because according to the grid is also not the bootstrap to the grid. It's a change for it. It's really quick, I don't know. Yeah. Are there alternatives to adapt certain plugins, meanwhile, that bigger transition takes place? Actually, I don't know. I think on the UI side, we don't have much plug or much work in plugins up to now. So the UI is quite limited in most of the plugins I know. Most plugins just use HTML and that's all. And what I'm concerned about is, for example, in the short term, is in the warning CENG plugin. Because it's the one with the one plugin that's actually using all of this and it's what, like 7% of the install base. So it definitely has a sizable number of installs. And it's expected to grow, right? If there's a way of changing warning CENG for some time, meanwhile, the grid and bootstrap is included into core itself, then that would be a way to smooth the thing. I know it's somehow putting work that later will be done, but if it helps to smooth in the transition, it might be an option as well. Something I wanted to propose, Uli, maybe we can discuss it further, is to sandbox the plugin views. And that's something that I actually want to explore more within the Jenkins ecosystem is that it's problematic loading lots of JavaScript, lots of CSS within the Jenkins, and everything will clash, right? But if you can sandbox within an iframe certain complex views, you can do whatever you want there, right? So maybe that's our approach we couldn't explore. Maybe it's complex, maybe it's not, but maybe I think that's something we can, maybe it's worth exploring in a transition period. Okay. Okay. Yeah, great. So anybody else wants to add something on this topic? Okay. Thanks for raising it. I think this is the right thing to do. We just, as with anything, we need to kind of try to do it cautiously and considerably that sounds like that's the plan, so. Yeah. Yeah. Okay, so next topic, archiving this Slack channel. So something I'll like to mention on the, on this on the secret Slack channel. So Joe, maybe do you have some updates on this? Yeah, just a small, small item. Essentially, we had some pretty valuable conversations when this SIG was starting to ramp up over in the Slack channel before we switched to Gitter. We didn't want to lose those conversations because they might be useful for reference later. So I got in touch with the admin or I guess the owner of the Slack organization for the Continuous Delivery Foundation. He was the only person with the rights for the ability to go in there and actually archive properly. So long story short, I have an archived file of all of our conversations from that time. If anyone has any preferences on where to put that, I could certainly put it on the resources list and link it in Gitter. And, you know, it probably isn't something we're going to need, but it has been successfully archived and we can refer back to it as we need to. Great. So we can thank you, Joe. So then we can move on and actually have the channel. We can forget about the channel then. Yeah, I mean, yeah, I would still request that we have a link or a zip file stored somewhere. You know, because I mean, it is great that we've done that work for now, still people can't access it and we'll have to request it and you can be explicit and already request. That's like, I don't know. There's the public zip or something posted somewhere. Sure. I'll put it right on the, on the UX SIG resources Google Doc. Thank you very much. Sure. And if there is a reference in case anyone has lost track of that document, we try to put everything that we share or discuss right here on this resources document. And if there is actually not another point to raise the discussion on the chat with Roman, let me think we, I mean, I already kind of raised it a bit, but I think we should have a page and landing page somewhere. Something like getting started UX page somewhere. That's like the always up to date information about maybe that's the Jenkins IO UX page, you know, you know, for anyone that would be joining us, you know, in the next week, some month, something that would avoid us, prevent us from having to tell people, Yeah, everything is in the running notes. So just go through it, the code through the team pages and find anything that's valuable and please figure out yourself what's what's stale and what's up to date what's still relevant, you know. So something like one page or something, you know, with like up to the links or something. What do you think. So you're describing like a simple page on Jenkins.io. Sorry, I just want to make sure I understand. Yeah, maybe I mean I'm not I'm not strongly be feeling about where it should be probably living with slash six page six slash UX page you know on the Jenkins website would make sense. But I'm not requiring it really just saying that I think it would be valuable to you know for people like Roman or anybody in the future. Something like you know in a few minutes, if you're interested, you can, I don't know, like a half page or a page, white length. You could figure out you know what he's for instance the mock ups because I think that's the thing we want to keep up to date somewhat. I don't know, maybe the link to the you know, G raw that's if you scroll down you will find the Jenkins epic on the issues you know something like these that would actually point give you a few pointers for anybody to jump into it and start you know, getting involved basically. Yeah, I would say things I would like to have and now I'm making the getting the context, but things I would like to have as a newcomer would be relevant to your tickets. And some of them pointed us new be friendly so for those that are doing first things in the Jenkins UI which ones are like easier to get started with. Also, the repo which I guess is a core repo but maybe them a few PRs that are good examples of the work that is being done in the UI. So these sorts of things that are the first thing you tend to look at when you're joining a project. I think that those would be helpful for me for people joining the group. Okay, thanks. So we do have have this web page with. Sorry, it looks like it's part of a longer link but it's just that last one I just put in the comments, which is the page for the UX or the user experience sake. It sounds like maybe we can achieve this by just adding adding some updating the resources on here. Essentially, okay. Maybe even have an actual bullet point list or something because right now I think also the hyperlinking experience in this site is not the best for me to see every difficulty. Yeah, I mean it is probably there's probably some limitations in the static generating the jet static generator system. Still, yeah, something like getting started, you know, part there would probably make a lot of sense and I mean I love what just Roman just said. If we can file some, you know, maybe split in building upon what you just you know you said also at the beginning or at least a few minutes earlier. If it's about, you know, splitting things a bit more trying to accelerate. I think we would actually be great if we are able to file a few things like we smaller and tagged as new be friendly because actually people will be actually working on these getting started contributing. And that's really what we want to hear you want people involved perhaps feedback better so potentially people to actually do the work to play with the software contributed Jenkins overall. I mean, it could be, you know, very first your single first your circle here. Yeah, I think that would be great because there is this barrier of entry that you feel overwhelmed about all the things you have to do. So if you have simple, simple ticket then you focus on how everything else works like the ecosystem and you get that thing done and then you get more confident and start building on top of that. Let's create a ticket for for Roman. I think it's really great. I would really like that. Okay, great. So, yeah, thank you everybody. It's an important point though just I would like to say that I mean getting more people involved in projects would be a good thing. I mean, it would help speed us up so maybe it's something you should talk about more next meeting or. Yeah, definitely. Especially if people want to tackle all the some stuff like we are not planning on doing but it definitely needs to be done. For example, there's a close PR by just sort of about moving the configuration pages to front tables to deeps. It's close to bigger fiscal but I think that's absolutely needed. I think that's that's a huge need. I mean, seeing as Felix is essentially the only paid full time developer on this. I mean, if we get more people working things that would just accept right. I mean, for instance, I'm thinking about something that probably would be actually doable by a lot of people who have the skills. New experiences we've discussed a few times publicly and possibly between some of us, you know, and about, for instance, the admin monitor thing that shouldn't really be called monitor. But it's, you know, monitor is only a thing only then kids admins come to understand at some point, but it's like an alert. Actually, it's like a notification notification thing. So, you know, moving it to the right and make it a bell only, like, you know, guitar, Trello, a lot of tools do to make it so so because we're talking about system phones here. But you know, moving to the right and looking like the others about like here's the notification and maybe it's a security notification actually have the different bell or maybe a red bell. I think that can that's why I think Felix at some point said that it was not maybe a big one. So, definitely maybe a good candidate for, you know, newbie friendly and then we would have been we'll be having people here and more review that PR and you know, basically be able to accelerate and then fulfilling what Oleg and others said. Yeah, definitely. And you are issues are great for newbie friendly because it was Roman said it helps you grow more confidence. And it's definitely more easy to verify that it's something rather than the not changing some Java protocol or whatever that how Yankees works underneath right. Yeah. That's a great idea. So that example that but this just mentioned is it was it but this about the typical notification we get in Jenkins when it's outdated, for instance. Yep. So switching that from where it is to the right and replacing it with a bell. Yeah. Yeah, it might be something we want to discuss a bit because we haven't been I don't want to contribute them just because but you know, indeed, I mean in terms of UX only experts in Jenkins I understand why the hell we call that a monitor. It's it's really an alert or notification, you know. And I think an issue has been filed recently by Jesse on the open source tracker about removing the term admin monitor and calling it alert or we need to come up with a term maybe, you know, and that's why I'm saying then maybe actually the right thing to do is and like to try and make it look like, you know, Trello, GitHub, and probably a lot of others, where there's no bells on the right. Yeah, that makes sense. You know, that makes sense. Yeah, it was it was created by it was normal, not marked as newly friendly. Yeah, definitely. I guess you can find it pretty easily if you look for you know reporters being Jesse. But anyway, yeah. The process is talking about like opening these these tickets and such and opening the process a bit more review process be really critical here too because one thing we have to keep in mind is that long term, we're trying to, you know, we've already taken some steps. We have to create a sustainable design system over the long term. And so I'm definitely open to the stuff we're talking about but we also have to be cautious that a particular newbie friendly PR doesn't conflict with, for example, the color palette that we've defined right stuff like that. Yeah, you know, I would be really. This is valid one. And at the same time, you know, if we define a new thing, do same, do whatever, and we don't kind of challenge it, make it go through actually like someone else than Felix being able to follow it. And then, you know, it's actually also going to be interesting to see how people understand the design, you know, rules system we've put in place to be compliant to be complying with it, you know, and then work together and I expect with the group of people here. So I think our team is reviewing every single PR is on the core. Uli is doing a lot of work. I'm not too concerned that, you know, we will be able to request a review from Felix from gave in who's are so pretty active and I thought people, you know, are knowledgeable about, you know, the UI. So I'm not too concerned about that. I think we should open in need and be still. Yeah, right. Not break the work or like be in the position of what we've achieved so far. Yeah. There's always an interesting balance for us to strike when we're talking, especially talking about the CSS work right because long term we were aiming for consistency but also we want to achieve it, you know, improve our efficiency so I think we're on the same page here. Absolutely. I'm not too concerned in the London page and the current topic about the new be friendly task and things like that. I think it could be really interesting to put aside what was decided to not be taken as a priority by the UXC at the moment to let the thing being done by new be friendly and Think like that to be sure that we are not taking the things from the workload from Felix innocence. If we want to provide some improvement on some UI and things like that. It's especially important to know that it's something that is independent and that will not take some conflict or things like that with what is planned by the sick innocence. So for example, the admin monitor is something that is definitely not inside the current scope of what Felix is doing. So to let the people know that they can take that task we thought perturbing the system could be useful. Yeah, or maybe even some tasks that we will handle in the future but people, if somebody, for example, if somebody wants to go ahead and set up a storybook to have a UI library, a UI component library visible, please, my guest, it's something that's tough work. So, yeah, we appreciate any contributions there. Just in case, Roman, the monitor stuff, it's also a security discussion there about the separation between warning and error and things like that. All right, guys, we're at the hour, so I think we need to wrap this up, but probably good topics and on agenda for next time to think about how we can bring more people on board. Yeah, we will think something about how to restructure the landing page, the sick page, sorry. So, thanks to Felix and Joe and Uli and everyone else for joining and thank you Roman for taking it for the first time. Thank you all, happy to help. Thank you everybody. Thank you.