 Alright, so I'd like to try something new Joe would you be able to share the agenda because it's quite hard for me to take notes while I'm also sharing my screen. Sure. See I'll see that figure. Yeah, my, my, we don't use the old word so my aged eyes need a little bigger. Yeah, there we go. I'm guessing you have a big screen whereas I'm just looking at almost 15 inch laptop. Okay, so I mean, we always start with reviewing the topics and I some of you have already had a look at this but Mark or Tim, whatever it is though. And if you have any topics you'd like to add. I just wanted to see how it's getting on. Yeah, for me. Okay. So, you don't seem to be any new participants today. As I can see, do you know everybody Tim or would you like an introduction because obviously, most of us know each other to work at cloud. Love me everyone I think. Great. So, in that case, then we can just go straight ahead to point three which is an update and how things are going so Felix has been working off it seems to be heading to the door, but it has been working pretty hard on getting some of the actual UI changes into products. So I think it's a nice if it's good. Give a little update on progress of changes he's been making what is wrong into. Joe will also be giving a bit of an update on sort of the intention behind the work and what's coming next. So you're ready to go Felix. Sure. Thank you. We shouldn't miss you now. I'll stop sharing first. Maybe you should be able to. Okay. You see my screen with the actual Jenkins. Yes. Okay, great. Great. So, you can see here. This is basically the our current development version of the new Jenkins. Of the thing is right with a new header and the new breadcrumbs bar. So yeah, it's mostly a perfect on the updated designs by on the on the document that you will talk about in a minute. So yeah, this is mostly what you can expect is it's almost there. We are missing a few states over states for some elements, finishing up some touches. But I think it's the end result was rather nice. Yeah, I think the activity monitor monitor looks good. communication. Yeah, also the search menu is a bit more modern right now. Yeah, well, I'll be talking later about the one part where I have some difficulties where the breadcrumbs, because we did we have some designs with where the breadcrumbs will be separated by flashes on the current page would be half a different color. But the way the breadcrumbs are set and programmed into Jenkins makes it really difficult. So I don't know what to do about that. I'll probably talk about this in a in a thread on the Google. So yeah, this is it. If you're curious, we can you can see how it behaves on mobile. As you can see on tablet screens. These. Yeah, these, these icons removed the name and the action name is hidden and mobile. It hides the search for the search bar. It's not. Yeah. So yeah, this is it. I mean, this is not the biggest change. But I think it makes quite, I think it's quite visual pleasant. And we found that it doesn't really class collage too much with the rest of the UI. So, yeah, does anybody has any question about this. Are there any other changes planned for the UI as first steps or do you plan to deliver on the big header in the first place. So we will be delivering this. The PR I will be creating hopefully then this Friday or next week will be the header and the breadcrumbs. Yeah, so one problem is that Jenkins has a color scheme. What you change doesn't map the color scheme on other pages. So, yeah, that's why I was wondering whether it would really fit. Well, I can create a PR for you mean for the plugin site and for the site is less of a problem. I would rather worry about other pages. Do we have an inventory of sites for that problem? I mean, we can definitely talk about this if everybody's happy with this color scheme. Maybe we can have a plan to update the color scheme for the other sites by the time the next LTS, for example, is released. What is the color scheme? I mean, is it an actual document? Yeah, I can find it out. It was somewhere, not under the trigger location. I don't think that just changing the header will be a big problem. Yeah, I don't know. Maybe we can... Well, I was going to talk later about how we can go about releasing these changes. Maybe we can talk about this after the presentation, but basically what I want to mention is what I think about what you said is that I suggest we go with it because we are going to be changing more stuff, maybe typography or maybe everything, and then we can update all the other sites at once. Once we have updated typography, color scheme or everything else. Yeah, but in order to do that, it would be nice to have a vision of this color scheme and whatever before we start merging changes so that we can review them together. Yeah. So what did you propose here? Well, my proposal would be to have maybe a set of reference screens, which would represent the new UI you want to deliver. And to actually get it through broader community review. For example, propose it in the developer mailing list with some sketches, and we can start from there. So if there is a consensus that it's the UI you would like to deliver, why not? So do you mean you are suggesting that we create full mock-ups for some key pages right now? It would be my proposal because I see this header, it definitely changes. But even here I can ask why do we have Jenkins text under the Jenkins text on the left top angle, which looks quite strange. Yeah, understand that that's how break ground work and that it's extensible, but as a common user, it would be nice to understand where we are going. So just to kind of respond to that idea of creating full screen mock-ups for the experience, I think it might actually do more damage than be beneficial. And the reason for that is because it's just too early, it would be a bit presumptuous to try and design all of these different elements on any given screen. So we're going at this really cautiously, so I don't think it would be the right move to incrementally, intentionally. I don't think it would be the right move to design full screens and send them out for approval. I think this call and our Slack channel are sort of the forum for discussing these things. So rather than creating those additional mocks and putting them out there, I think this call and Slack are where we should talk about them. So that Jenkins and Jenkins thing, if that feels weird, that's great feedback and let's talk about that in Slack rather than creating a new process. It's not a new process. Okay, so maybe this is a process I'm not familiar with. Basically just to have a complete proposal. Because if you submit this change for the header, yeah, it's fine, we can vote for that. But yeah, for example, I don't understand where it's going. And if you expect me to approve it, I won't approve it. I'm happy to be able to vote it in the pull request, but I wouldn't vote for that in the current state. I think UI is important and I would really like to understand why we want to get these changes. Sure. So I'm curious to learn a little more about this and sort of what, what would get you there like as far as like how much detail do you actually are you seeking, because I don't think it, I don't think that we keep providing accurate representation. Yeah, I could make full screen mocks, you know, no problem there, but I don't think that they'll necessarily be an accurate representation of what we could achieve. They could show maybe what we want to achieve. But they're not going to be things are going to change, you know, as we as we work toward it a proper design system in the long term. So I don't want to be providing you with things to review that are going to that are not just going to be an accurate representation. So maybe maybe I'm confused, but where are you referring to mockups of the whole new design or just of how the new header would look like on another page. For me, it's rather several pages, but to use new design. So currently we changed on the header, but everything else on this page is the same as it used to be before. So you don't like the fact that you don't know where it's going basically. Exactly. Yeah, I know no one likes that right but it can't it can't all be designed in bulk that way. And while physically I could definitely design that for you. The thing you would be approving wouldn't be accurate. Okay, then the question why does it have to go to the Jenkins core, because we can have a separate theme, and we can integrate it once this theme is complete. Because well, I don't think we can do it as a theme exactly because it requires some actual markup changes. Yeah, but markup changes is something we can start doing. Yeah, that's something we I wanted to touch later, which is how do we go with releasing this. Because we, we have talked before about that we could use feature flags when necessary. So maybe with maybe you, you, you, well the community would prefer that we release these changes, instead of straight to core behind the feature flag or whatever, so that the users can develop the new UI. Yeah, if we could do that, it would be nice. I mean, it's some kind of compromise you can reach because I mean, I understand what you're saying. Oh, I mean, I'm also, I'll be honest. I also don't know where this is going well enough. I mean, I like what I see so far, but it's, you know, it's like two percent of the Jenkins UI. I don't think it's particularly healthy for Joe to make high fidelity mockups of you know, 90% of the Jenkins UI. But so how can we find some kind of middle ground where we have a better idea where we're going with, you know, flexibility to make enough changes that, you know, we're not designing everything up front. Yeah, for me, it would be nice to just have, let's say three pages, one is front page of Jenkins, this may be some jobs, some folders, which is a common keys, then a page for a job and a page for a build. So these are three main pages which have been visited by Jenkins users. If we could have understanding how it would look like for them, I would be totally happy. I don't really care about configuration pages because well, we go towards configuration as code. I don't care about other peripheral pages, but if we have vision for this common keys, I think it would be great stuff. Can you please repeat what three pages? Home page, page of the build, page of the job, was it? Yeah, maybe also build look if you consider doing changes to that. So I don't think that's entirely unreasonable, right, it's just the thing to remember is that it all comes with a huge asterisk mark, which is to say that the design will change from whatever I'm providing for you. But I think that's fine. I don't want to commit to when I could provide that for the SIG just yet. So let me figure that out and I'll post an update in Slack. I think there's a middle ground to achieve there. Let's figure it out. For me, feature flag proposed by Felix would be totally fine because I believe we have a consensus that we want to change the design. Yeah, we wanted to avoid the feature flag as much as possible to the less number of features as possible because it definitely makes everything harder. But yeah, maybe if you do believe that they are necessary for this first step, sure. But what I will be doing is probably I don't have enough knowledge of the Jenkins Java side, basically, to speak. So I'll probably be requesting some pointers from the community maybe to how do you prefer it, maybe as a, maybe for example, do you prefer a toggle switch on and off through the configuration panel at runtime? Do you want to set it up as a startup flag when running the binary compile time flag? You know, there are several options. Yeah, this is something we can take offline. Okay. Also, well, I think you joined late. This is basically the new header we've been developing. Uli, do you have any thoughts of what we just discussed? Yeah, I just followed the discussion. So just fine. Yeah, I'd also like to welcome Angelique Jard who also joined late. Oh, she joined. Yeah. Yes, I'm here. I'm just listening. Okay. I'm listening. Yes. Hello. Welcome. Also, some changes could be actually delivered incrementally. So for example, if you want to just lend this notification bar, I believe it's something we could do right away, because it's definitely better than the current layout. So the problems start with color changes, with styling changes, because there is a lot of users customizing it using simple team plugin. And if we just break the layout to a new header, without UiRiva, it might have a lot of issues downstream. So do you understand you correctly that maybe I could upload on the PR where I create. And then put behind the feature flag, the new Ui layout, which is with the current with the former colors with the black bar and stuff. And then I create behind the feature flag, the new colors. Yeah, it's one of the ways. But yeah, maybe I wasn't specific enough. This top panel, which we change basically consists of a number of controls. But what companies usually change is the logo on the top left and the color of the bar. So it's pretty common to replace it. So as long as we retain compatibility there, and maybe keep look and feel the same, the rest of the companies that can be modified. So if you want to modify the bar, I don't see any issues with that. If you want to modify notifications layout, I also do not see any issues there. Okay, so you're saying that the problematic part is the logo and company name. And, and I'm, I'm really impressed actually by the, the way you've improved the experience for the user on narrow screens, the collapsing of that admin user and that log out. That's really nice boy I'd like to have that sooner rather than later. That's really nice and I don't see any reason for a feature flag for that. That's not a commonly customized thing. Nice work. Thank you. Appreciate it. I look into that, definitely. I'm thinking of what I would like to mention one thing before moving on. Which is that we did receive some feedback from the community, especially from Uli. Thank you for that. For example, we, I'll be, maybe you'll be surprised that I'm adding new modern front end techniques when by the time I create the PR. For example, I'm using a new way to adding icons, which will enable us to use the whole suite of material icons. Yeah, that's a heads up. You can expect that maybe some things will your attention when catching your attention when by the time the PR plans. But I will be working on that. So if nobody has more questions about this, I, yeah, Joe, you can go ahead. I've got one. I'm not sure if question or suggestion, but what do you think about the enabler to refresh link or button or whatever because when you stress the thing, it's weird, because I think it doesn't It's currently almost the same behavior as now. I didn't want to touch it that much. And the reason for that was it's probably going away. So I did not want to compromise basically the most layer for something that it's not many people from what I saw many teams actually disabled it. Yeah, I, I, in my opinion, I would move it away. So that's what's planned. I mean, I'm becoming here. So the developer is about that. Yeah, it was really weird because some plugins with 1000 stalls are actually hooking up to this deep and doing some weird things positioning themselves there but that's why I didn't also want to touch it that much. Thanks. I will stop sharing then you can, you can resume sharing. Here's sharing, please. Okay, no problem. Thank you. One thing to keep in mind regarding the ICANN management. This just caught my attention. We have a history from producing new framework for ICANN management. You can take a look at ICANN shim library and ICANN shim plugin. Yeah, it's not, not the engine I propose but we all have an engine for managing ICANNs. And it might be compatible with what you consider doing. Okay, I'm just using SVG Sprites. I'm thinking the SVG Sprites straight out of material is just a way of using just the whole materials with the ficons that Joe can talk about it. We will quickly will be trying to use material icons as much as possible. And sometimes we will need specific icons. And the reason I wanted to go with full material icons and a standard weight and standard material icon suit is that anybody can go choose a material icon they want put just an imported like that they will create. Yeah, but one thing. So if you use standard library will be downloaded from the internet, or will it be a bundle is the resource. You can actually download the SVG simple files and put them inside as an asset basically. Yeah. Sorry, what are material icons? Is this just the icon itself? Yeah. Yeah, the icons for material, for material design from Google. Google releases a standard suit of material of the icons they use. As SVG file the definitions and you can use them freely they have Apache Apache to license. So I think they can be safely used. And we already using this or we plan to start using them. I'm actually incorporating them into the in the they will be featured for the first time in my PR. So I took some liberty to add some new stuff. And I was expecting the PR to have those discussions and then I can dial it down and provide some stuff if the community doesn't like those techniques. But oh, please, can you please point me to those tools that you just mentioned. Yeah, I'll put them to the secret. So we get a couple pretty straightforward slides here. Our last meeting due to the holidays was just around a month ago so there are a lot of repeat slides in this deck from that one in case anyone needs to needs or wants to go back to check them out. Naturally I will link to this slide deck in Slack after the call. So there's some housekeeping stuff that we don't need to run through again I don't think but sort of what's the intent behind this document. We're trying to find the visual refresh, evolving the Jenkins grand focus on visual accessibility and long term wanting to work toward a Jenkins design system. So, like I said, we don't need to read that all word for word. We can take a look at some mocks here and because we had that update from Felix this is essentially what you've already seen. There's some discrepancies between what he's working on and what I have in these mocks and that's because since the holidays we've already been kind of talking back and forth and improving things on his end that the design mocks just haven't caught up to yet so there might be some discrepancies but essentially we can run through the updates real quickly. So this is sort of repeating, but functionality will remain the same as the goal. We're introducing this new color pilot and modern iconography. We wanted to start with the header bar for these reasons in additional details on the screen. I don't think we need to run through all of it so go to this next one changes since the previous meeting stuff that you've probably observed already. UI palette has been adjusted. It's actually looks pretty different from the from the previous iteration. You might have noticed. It's got greater visual contrast. As Felix mentioned, we've committed to material design icons because they're easier for implementation and they also just have their, excuse me, have their designizability and and are really easy to understand for a lot of people as they're using a lot of different products. They're very accessible for for third party developers for anybody who wants to to contribute and use the same icon set. Some material icons and that was also directly for some feedback from Uli. So thank you. Our suggestions have that new treatment improve eligibility there. We added labels back to those icons. Small things like this. So we're getting very, very close on this one I would say. And also Felix mentioned and showed their own screen which is a lot better than a static mockup. Having designed considerations and some graceful degradation for smaller screens. Like these mocks aren't actually caught up to what he's already developed. So that search would be hidden, for example, but if the idea. Yeah, if I may point something about graceful degradation. Also, we want to keep. It's not realistic to expect that all the everything will look the same in all browsers, right. We don't want to be limited by browser. For example, we don't want to be limited by CSS properties for browsers not having CSS properties right now that they will eventually have an example for this is pretty small example for a technique that we will be using in the future is that you'll see this nice diagonal bar on the head. So for example, yeah, where the lowest. It's a has a diagonal border, right. So that uses that's done and easy way using a CSS property so on browser that do not support it is just a normal rectangular box. But browser that do support this nice visual effect and this nice visual property they have the updated. They have the updated basically styles and the other browsers will eventually catch up. This is really a really small example and maybe not the best example but that's something we will. I want to make it a point that this is something that we will probably be worth you doing, which is making sure everything looks great on most modern browsers and the others will work and eventually they will catch up. One question about it. So we updated the browser support policy in December. Taking the current support policy do foresee any breaking changes. So if something doesn't work like this CSS properties perfectly fine. No, no, yeah, actually, I, I just thought I just tested today on the internet floor 11 and everything works except the icons but I have a polyfill for the icons. So they work. Okay. Thank you. Awesome. And the final thing I had for for today was just sort of to give an idea of what we're going to be thinking about next. So, up next on the list here as we finesse the header bar. Keep in mind that type this out before we actually met today of course. So we will, I will follow up in slack about that idea of providing some some full screen mock ups and we'll figure out where to to meet on that only. But prior to that bit of discussion. Here's what is on the docket is admin monitor warnings. As a type of component and of course they will go and go ahead and inform other styles throughout the interface like buttons and, and other possibly form elements and things like that. And then a little more broad Jenkins typography. A lot more broad actually. So feel that it really deserves dedicated consideration. Right. So obviously there are huge implications with something as simply stated as Jenkins typography. But I don't have a lot of my, my exact thoughts worked out on that just yet but in the next meeting I'd like to share some ideas and more specific proposals on how possibly can be improved to to improve accessibility. And that of course goes right hand in hand with functionality. But these are two things we'll talk about two weeks from today, in the next thing call and I wanted to mention them in case you want to talk about them in slack leading up to that, or right now, totally fine. Any questions there. Maybe talk a bit more about your plans for topography. I mean, I've been mostly warning sounds pretty obvious. I mean, the topography. So, so where I have to start is kind of doing a bit of an audit audit might be too strong a word but sort of a bit of an audit to see where things stand right now. I don't want to say we want to improve consistency in the typography throughout Jenkins because I don't think it would be fair to say that it's inconsistent right now. I just know that there's probably room for improvement. And that certain places things need to be larger. How we treat labels. What's most readable in paragraph format and just just a lot of different considerations font choice of course is a big one. Do we need to change it is that something we should be talking about so a lot of question marks here for the moment, but because type touches so much of the experience. Like for us to think about very soon so we'll talk about this in the next one more. Nothing too specific yet. We're going to move to comic sans. Yes, that's right. Yeah, that's it. We're doing comic sans across the board 32 points. Apart from the type itself is also about font sizes. Because your font sizes is a pretty, pretty pressing topic on Jenkins. Yes, absolutely. Yeah. And can you elaborate what it is and I'm sure we can guess what he got. For example, even if you just open the previous interface shared by Felix, etc. We get the feedback that fonts are just too small by default. Yeah, when you start scrolling in eventually your panels go in different directions. For example, it seems extremely difficult to just present the Jenkins for example, if you're doing the talk. Yeah, because well, you know, with the current layout with the current fonts, you either don't see fonts or the way out just full support on the project. Okay. So if it's a part of typography research and definitely plus one of doing something about it. Oh yeah, on selection and size. Absolutely part of us. And that's it for now. Just quick reminder here about providing feedback. Obviously we have our slack channel, you no longer have to email me we found a way to set up a direct link thank goodness so just click on that if you want to go enjoy this. If anyone here isn't already in there I think we all are a comment here. Oh yeah that's true. It was a great point I'll like yeah. Yeah, we do a lot of demos and they're essential to promote the Jenkins at conference talks, and they show you that demo and can you think was Jenkins for the holidays. Yeah, great example. And that's it for this deck for the moment I'm going to go ahead and switch back to the agenda because I want to remain mindful of the time where we got a lot to go through. Felix did you want to say anything more about release approach for this call. We did talk about what we did a lot already. Yeah, you're good. I just wanted to double check out. Yeah, something that. Yeah, by the way these changes, just to mention these are relatively. They're not the only impact up to one plug one plug in that I think of which is the warning Sanji. But yeah, really and I have been in contact a lot discussing how to solve this. So, awesome. It will eventually not be a problem. Yeah, one question. So would it make sense to start creating Jerry tickets and maybe to create an epic for this UI changes, because if you want to have an incremental approach, having an epic and whatever would help us to see what would be the pun. So even if some tickets are just ideas at the moment by having this list, actually it could help to drive this discussion for you. Yeah, that's something that I thought of yesterday and I forgot to add to the agenda. Thank you for for bringing this up. I think it can be better, especially if the community has a reference to something that I mean is is also just good to have an opaque discussion and then just create a PR right maybe for the for other community people who are not following the way it can also be a good idea to, to create a ticket and have a way to see an epic a backlog to have more just tasks that are not only adding UI elements maybe to report the bugs that are specific for the redesign. Yeah, it would be helpful and could also help to facilitate changes. Because yeah what we usually recommend is if you see that the ticket is new different the market is that and it's likely that you will get somebody working on that. I'm not sure whether they would be new friendly tickets right at the moment. But still just having it publicly visible and traceable helps us to get more attention to the project. So this would be obviously Jersey is not in the cloud is your but in the public Jenkins Jira. Yeah, that's for sure. Yeah. You're, you're aware of the public Geron to Felix. Yeah, yeah, I did raise a few a buck or two I think I'm going to raise a few or two and I did I participated in a few tasks there. Yeah, so maybe we can, we can talk offline how to maybe how to organize create an epic or something like that. In Jenkins, you usually use ethics and use them as a group in Caliment to group my projects. So, yeah, I know that's not how ethics are supposed to be used. But historically, it's the most dominant kind in Jenkins Jira. Maybe we need to create a component or a project or something also. We could but a component on like we have Jenkins core and other components, for example, warnings and G plug in, if you want to do some downstream changes to keep the things compatible and epic is just a group I think pause. Okay. Item number four. Sorry, I'm just watching the clock here. Jeremy, do you want to speak about that one? Yeah, sure. So I mean, we need to kind of move towards having a fixed slot we've been fairly ad hoc up until now. I think we've had a few different times. But I mean, I think the two weekly cadence is about right obviously Christmas New Year came in between those. Anybody have an issue with it being at this time? Or should we make it earlier because I noticed in the Jenkins calendar there is another meeting right now. The pipeline and just get my calendar. This is I think for me it would be a little bit better if we can start one hour earlier. It's not meeting one hour earlier. One hour earlier we have what you so called for sales. It would be quite difficult to move. Okay, then it's okay. It's okay. For me, the Tuesdays are quite difficult at that time, because I often work meetings that really need to dance. I mean, I'm open to moving into the Monday or Friday Mondays Wednesday. I mean, it's okay on this time as well. Yeah, this time works for me as well. At least with this time, I mean, if somebody from California wants to join, they can join relatively easily. Obviously, we're locking most Asians out unless they want to stay up very late. Yeah. Yeah, but in the worst case, it's possible to just have another series of meetings. It's what we're trying to do in JSOC and focusing outreach for our region and Europe have early meeting. So we have to have two time slots. Yeah, it's also possible. So we're agreeing now that the meeting is going to be at 5pm European. I think we're all in the European time zone, aren't we pretty much? Yeah, so 5pm CT, I think everybody on this call is except 10, you're in the UK, aren't you? Yeah, UK. Yeah, so 4pm UK. Okay, next week, I'm not going to be able to. I mean, in two weeks time, I won't be able to attend, but I'll make sure that somebody takes over. Okay, so that's pointers agreed. Alright, so yeah, it won't take much time. So actually my proposal would be, so one of another reasons why I was talking about mock-ups for the entire UI. Maybe it's time to start facilitating in the community and creating some buzz for the Jenkins UX seek. So once something could be presented, it would be great to have a blog post on Jenkins IO and maybe to use other channels to highlight these activities. Because UX is on the top of our list in terms of user feedback. So if we just show that there are some things happening in this area, we can probably attract more contributors. We could attract just more users providing feedback about the UI and it wants to be changed. So my proposal to contributors would be to actually have an announcement once you're ready. Yeah, I think that's a good idea to have a blog post and obviously I think it would be good for the blog post to have some kind of collateral like an image that shows, you know, where we think it's heading because that's obviously what gets people. Reading about UX is boring if it doesn't have graphics. Well, so even the first meeting, so there was this three-phase project plan. Even the old deal looks interesting and something to be shared because you can definitely get a lot of feedback for second and third phase. But if it's accompanied with some of your sketches, yeah, I think we would be. Yeah, so let's see what do we want to have in the blog post? Obviously, we're going to talk a little bit about the SIG, but the SIG is not really what the blog post is about. It's more that we're planning a new UX. I think that whatever is interesting to users. We had some announcements for SIGs before, but usually it's either many tests of a special interest group. So what we want to do, why we invite people, how to provide feedback, how to contact us, or maybe some highlights for project activities. So for example, from SIG, we start from Java 11 right away. And I guess we have never formally announced that this special interest group. Yeah. All right. I mean, this is something I'm happy to take the lead on. It will probably take a week or two before I can get it all done. But wow, I guess it also depends on some mockups. Yeah, we, like I said, I'll follow up in Slack about what we can do there. But yeah, it'll be a little while, a couple a week or two, as you said. And then item number six or like. Oh, it's the same topic, basically. So if there are SIG members who are going to FOSDOM, we have a contributor summit on January 31. And it would be an opportunity to have some UX related discussions. If there is a critical mass of people who are interested to talk about this topic, it could be an opportunity to meet face-to-face. Yeah. Might be the same mouse for Felix to consider. Yeah, and obviously everybody's welcome. But I mean, Felix, does FOSDOM is? No, it's pretty. Maybe I can give the one minute or 30 seconds. Just the biggest open source conference in Europe. Okay, it's enough. Well, it's really big. It's more than 10,000 people coming. It's a two-day event on the weekend. There's a lot of things going on. For example, Jenkins will have a stand there. And there was a CICD room being cleared by Olivier Vernier. And in addition to that, communities are going to have various meetings around FOSDOM because a lot of people go there anyway. And FOSDOM, we do the contributor summit on the 31st of January. Who's joining me to prepare some materials? I actually was going to release an image with the new UI, with the new changes. So you can try them. It's not something for planning, et cetera, but it's rather for discussion. So for phase one, I believe phase one is more or less discussed. But next phases, like which frameworks to use, what would be the roadmap for that, it could be a good venue for such kind of discussions. Oh, yes, definitely. Yeah, those will be lengthy discussions and happy research involved. So yes, just an opportunity and I believe there will be more events later this year. So there will be DevOps world in Las Vegas, then in Prague. So if the project, if we have planning and design work at that time, it could be even a better opportunity because there will be more people there. Yeah, let's see. So I just referenced this item. So if anybody goes, we can use it. And I think that is it for our items for today. Thank you, Jeremy, for the notes. I'm going to go ahead and stop sharing. That's anybody else has anything they would like to talk about, otherwise we can call it a day. Just thanks a lot for doing that. Thank you. You're ready for the feedback. Yeah, thanks. Thanks for joining. Thanks everybody. Good evening. Good morning and good evening.