 So everybody have a chance to ask out of the meeting now that's being recorded and Okay, so everybody welcome to the first meeting of the Jenkins use experience special interest group What I want to do is quickly reviewed agenda and then I think it might be better if everybody introduces themselves and Mentioned their interest and then once that's done we can kind of Loop back and agree on agenda topics just to make sure that everybody's covered After that, I'd like to just have a discussion on the scope of the user experience special interest group which I'll be together with Joe Brugin We're going to review cloud based plans for the UI UX So part of what's driving this and I'll talk more about this is cloud based has some quite big plans in this area This will be driven by myself by Joe by Felix Kurega. He's just joined the cloud these teams Um We're going to look at strategies for making changes To the UX without breaking plugins, which Felix will be leading Finally, I'd like to talk about how often we should do these sessions reflect on where it's valuable or not What we did is every two weeks or every month Any other business obviously at any point people are free to bring up topics so Let's just start with a quick round of introductions because um, I don't know everybody on this call I'm sure everyone's called doesn't know me either. So My name is Jeremy Hartley. I'm based in Amsterdam in the Netherlands. Um, I've been With cloud these since the first of april Um before the first of april. I worked various different roles in dev ops So I worked for a company called cb labs on an automated deployment product before that I worked Building a ci cb pipeline for a very complicated product in the internet tv space. So I really cut my teeth on what it means to take a project from Being in that classic scenario of having three to four month release cycles where the series it lands with your customers everything being broken To having you know, fully automated pipeline going from all the way from unit test performance testing and all the steps in between so That's a little bit my background within cloud bees. I'm responsible for Jenkins and the cloud bees Jenkins distribution um One of my special interests is user experience. I mean one of the things I've wanted to do since I joined Is to overhaul the cloud bees or I'm sorry, excuse me the Jenkins UX and um So I'm really happy that um, we are now restyling this process so I'm just going to ask Felix who's next in the uh video List to introduce himself and then we'll go through people one by one. So Felix, who are you? Uh, hi, I'm Felix Keirova. I'm I'm located in Galicia northwestern Spain Uh, I'm the frontend engineer who I have joined cloud bees recently Uh, and I will be working on the Jenkins UI basically um Well, I will talk about this In more detail later I'm I'm a bit new to I'm to contribute into Jenkins itself Although I have used Jenkins in the past and I am familiar with the theme points of UI. So I'm Eager to help improve this situation So but yeah, I'm happy for this project. Thanks Uh, Baptiste is next in the list of my system. So who are you, Baptiste? Yeah, so do you hear me? I think you're correct. Yes, we do So, uh, yeah, I'm Baptiste, Baptiste Natus. So, um, I've been working on Jenkins Since he was called a bit differently starting with an H a few years ago And so I have been doing that for Probably a bit less than 10 years and I've joined cloud bee three years ago Since a few months I've switched it switched to the tax side And being engineering manager. So I Do a bit less developments those days even if I'm still involved and Uh in Jenkins in general for various reasons for personal and professional reasons. So Yeah, and I'm here to help and trying to Keep Jenkins The best uh cac server and automation server in the world, I guess And hi everyone Already met Uli and the others already I know and team. Hello first time we see you in a call All right, so next to my list is Everesta, so if you could introduce yourself Yeah, sure. Thanks. I am Everisto. I'm based in Malaga in the south of Spain. Uh, I joined cloud bees little More than three years ago uh And I have background as a software engineer. I was also sometimes working as a front-end engineer So my interest here Basically come from the usability standpoint because I consider that something basic For for for a product to be interesting and successful. I'm also from the technology point of view. I think Nice and great things are happening in the front-end world, especially around the Developer tools. So it's it's a lot of There is a lot of interest in this happening. So that's why I'm interested in this and I think this is really interesting and nice So next in my list is uli hafner Um, I'm uli hafner. I'm based in munich I'm a committer on Jenkins. I think for more than 12 years now So, um, my interests are I'm the author of the warnings plugin And yeah, I'm you're contributing to this plug-in. Yeah 10 years now And I'm always trying to improve the user experience for the plug-in And yeah, so I'm quite interested what's happening on the tank inside to improve the overall user experience So maybe we can join our ideas and help to improve Jenkins and our Yeah Thanks And didn't you recently get elected to the board or you're in the process of that Congratulations. Thank you. Yeah, I'm not sure if it's really official yet, but No, I just realized as I said it that I probably spoke before Will have to be sworn into silence. I think people inside clouded my information No, I think it's actually because I heard that it's it's kind of unofficial But at the same time from a link Accessible from every for for every borders you can access the ballot or something. So, you know, it's not really private And Anyway, many congratulations on that. I'm sure you make a good addition and just one last question you're attending the Jenkins world in Lisbon No, sorry. I don't have the time this year Makes you're probably again, but not this year. Okay. Thank you. So Tim jack home. Well, have you pronounced maybe Well Most people pronounce it differently. Uh, jake and normally but I've I've I've heard it five different ways. So it doesn't really matter too much Um, hey, I'm tim. Um, I've been a user of Jenkins for about Five years and a contributor for the last year and a half Um, maintaining a few plugins for the last year slack configurations code and zero key vault Very interested in helping to improve uh, the UX I guess quite a lot of issues on the slack plugin with a lot of users and options and doing doing the best but Anything that we can do to help user experience from the Jenkins UI to help guide users would be very useful And you know help lead a team that across A few hundred developers using Jenkins for our cd platform Um, and to anything that we can do to help Make it easier to use for them. It's great as well All right, why don't you work out if you mind me asking? uh, I work at a company called canos. So Which is a irish company or not a company in northern ireland Um, it's a consultancy Okay Thank you All right, so Next in my list is joe brugin What did you orage yourself joe? Not yet No Hey, everyone. My name is joe. I'm a product designer So another other term being user experience designer at cloud bees Working on Jenkins and Jenkins related products at cloud bees Really excited to be digging into this topic and to be getting feedback from all of you in the community and and working together with you on this um I think I think that's it. I joined cloud bees back in early 2019 Uh, happy to be here Okay, right. Itran is next in the list Hi everyone, so I'm adrian. I've been around Jenkins for more than 10 years now When it was named differently, I've been contributing on plugins mainly For almost as long Creating plugins for different companies of supporting or fixing plugins for on consultancy contracts And I'm joining here to I'll make Jenkins a bit better on the UI side and hopefully Golden a bit a bit the the name of Jenkins on that okay So last that I have here is Carl Schultz Carl, can you introduce yourself? Hi everybody, uh, my name is Carl Schultz. I am a software engineer at cloud bees I've been working with Jenkins for I guess about four years. I joined cloud bees about three and a half years ago uh, and one of the Things that was shown to me as a thing that I might be working on would be uh was was blue ocean as it turned out and ever since then uh usability and user experience improvements to Jenkins have been something that has been really super interested in And I only just found out about this meeting about 10 minutes ago and thought well if I'm going to be the person that's Always asking if we can make things better. I uh need to also participate in the meetings. So here I am That's great. Welcome So I think that's everybody if I missed somebody it's a little bit confusing the list on scene But if somebody was missed, please Speak out now Take that as a no So in terms of the agenda, does anybody want to add a topic that they would like to discuss? It's fine for me Anybody else no, I mean if something comes up, I mean, I think we have Depending on how long we discuss each item. We potentially have plenty of time that um, please raise points as they come by um So I'd like to quickly discuss. I guess the scope of the user experience sig and why are we doing this? I mean, I think the the main reason why we're doing launching this sig is that um We've come to realization over the past year or so that Blue ocean is Not going to be what's originally was promised to be so the original goal of blue ocean Was to obviously start out by visualizing pipelines, but it was meant to Spread out and you know become the new ux for all of jenkins and Due to a number of issues Mainly around extensibility this turned out to be harder than anticipated and At some point The decision was made to really rescope blue ocean to being just about pipelines um And I think for some aspects of pipelines blue ocean does a really pretty good job, especially around the visualization I mean, it's not perfect, but I mean it's something that I know from experiences used by a lot of people and It's not a candidate to be replaced very quickly, but I think The rest of jenkins ux looks old. I mean, I remember Whenever I used to see jenkins before I was the project manager I used to Think wow this ux because he is a bit of love And you know something what we really need to do now is to really think and we're also getting a lot of feedback From the market slack, you know jenkins looks old You know jenkins is ugly, you know, there's a lot of negativity around this and I think it's Even though jenkins is you know, the number one DevOps tool. It's a super powerful product Which I don't think I need to explain to everybody If the first thing you see is outdated ux, then it just doesn't really give you a good impression of the product so So Based on all this, I mean We want to start an internal movement in cloud bees to Really build in the ux for jenkins. We would like to get as much support from the community as possible we want to Learn from what went wrong with blue ocean Um One of the things we really need to decide is is there a way to completely overhaul the ux of jenkins And leave no plugin behind or is this something that's simply impractical and impossible And if glatter is the case, which I'm not haven't decided yet, and I'm not sure about but let's say it is the case then What criteria do we do to get, you know, 90 percent of the plugins to come along with us? So these are some of the fault processes that have gone into this sig Joe do you want to does anybody want to talk? Sounded like someone was going to say something anyone want to try any? Okay, no, I always have something but I think Uli maybe and Uli, I know you've been doing a lot of work around adding things like Bootstrap and things like these directly in warning's ng so You know very we have a lot of experience trying to make things come all and back work about you both So what do you think about the feasibility of keeping? Every plug is compatible. You think it's feasible. You think it's desirable I think it is really desirable and And it's I think we should make or we should provide a tool set for plug-in authors And they need to adapt to these changes And not the other way around I think blue ocean started the other way around to say here is the user interface and Let's see how the ocean can integrate with the plug-ins But I think we should make it the other way around to say here We have a tool set that everybody can use And then we can give the possibility for each plug-in author to rewrite the plug into the new ui guidelines for instance So but then you're saying Go on Go ahead I was going to tell ui. I mean so you're saying if these variable But still do you say saying something that that's that is music to my ears is like We need to also be conscious that it's going to be hard to keep people working without doing anything But if if what you're saying is that you know, we are going to define what's what's okay What's not okay to keep things working and then plug-in author we have to adapt then I fully agree because you know And and for older plug-ins that have not been really in since five years or whatever I'm not very confident that we can keep every single plug-ins, you know in the case community Working without changing anything while still, you know keeping Jenkins free relevant and modern everything nowadays It's kind of my concern. So I was just going to say really I strongly agree. I'm really glad you pointed that out and it's not really On the agenda for today just because it doesn't have any any substance to it yet But part of the the long-term strategy here is certainly providing a toolkit of sorts our development resources so that um, you know plug-in contributors such as yourself and Just everyone in the community has the opportunity Uh to benefit from the investigation that's being done for this project and bring that knowledge Into their contributions rather than saying we've made a change. We've made xyz changes Hope you can adapt strongly agree. Well, we'll be working toward providing tools and guidelines and resources around that stuff Yeah, if I may say so That's also something that I wanted to elaborate. So maybe we can talk about this our one When we are going once we talk about plug-ins In more detail, but I think this isn't something nice to mention about phases and the On the google document. It says we have different phases And the first is the CSS overhaul. So the first I think our first goal is making the UI relevant But I think we can all agree that in the long term having a At the anywhere from a UI library to maybe only guidelines It is necessarily it is necessary to help plug-in maintainers keep the UI And I guess we'll talk on point number four. We'll get into it in just a second But just to add on to what Jeremy was saying about the nature of this this SIG, right Jenkins user experiences Obviously a huge topic. Um, and this is so this won't be a At least the current thinking is this won't be like a temporary SIG that lasts a couple months and then maybe We move on to other priorities. This is going to be a long-term topic and therefore a long-term Sort of group and meeting and we're going to start in with and we'll get into the phases in a second, but We're going to start in with with more Aesthetic stuff and then get into tackling deeper user experience and usability issues, but But that's all I had to say on that for now But I mean just one question for early I mean, let's just assume that we come up with some guidelines We come up with a kit and you know, you need to Let's say on average a plugin developer needs to invest one day worth of work to make their plugin work with the new I obviously some of them will need to do nothing and others Will probably need to do weeks work What percentage my concern I guess is that 10 20 percent of the plugins will come along and at least initially For the first year or two 80 percent of more of the plugins will be left behind What's your feeling about this or do you think that I guess this is my concern. I mean, this is the this is the biggest problem. We have I guess is Yeah, I think we already have 50 percent of our plugins which are left behind because nobody's caring about them anymore So These plugins will Yeah And we have we have some stages. Maybe we can say so we have a stage of quality plugins which are maintained That that's really interesting because that thinking we we touched on recently again because you may remember the Essentials Jenkins essentials are really cold and then Jenkins evergreen within evergreen There was something about these defining essential plugins that would be like higher quality plugins like in the short list of you know things that are done more than than the others and Yeah, I think it's it's something maybe that could be leveraged around that really indeed To to to designate the plugins the community commits to maintain over time and there's a long long tail of Plugging the ways let's say hundreds installation That probably if they need to be adapted won't be or you know, just maybe later or whatever I guess I mean maybe since looking too far into the future But I mean it would be nice if If let's say there was some kind of fallback mechanism that you know to look good You have to follow these guidelines if you don't follow these guidelines It's not going to look good, but it's still going to work Um rather than you cannot use this plugin anymore or you can only use it in kind of headless mode almost, you know Because that's obviously a very dangerous move if we're going to do that I'm in blue ocean. I think we had this exit button where blue ocean could be exited to this old user interface Yeah, I think if we have a little bit more Moderate that we have the few with the new plugins And then we have a link where you see the results of the old plugins for instance. So you don't need to Enter a new mode in Jenkins, but you can still see the old results But not in the new user interface Nice Yeah, I think it it's something that we will need to look into at the same time. I am not fully convinced that you know the the level of Cost of energy to maintain some things that anyway are For instance de facto debt for for a few plugins that are used by you know, like installed 40 times around the world So, you know, I'm wondering if it's not even better to consider, you know, adapting like 50 plugins like it was done for the Security problems like the security 400 or 200. I'm not sure. No, the white listing instead of black listing There's a few things like these where not many many dozens of plugins were patched But I'm not just sure that we need to break everything I'm just thinking that like really related to the the blog get that because you can wrote Two years ago, maybe the shifting years one saying to keep Jenkins relevant. We need to accept to Um, I wouldn't say break because that's not a goal But if some things gets broken because we keep Jenkins relevant and keep Jenkins great And even newcomers don't feel what we're discussing right now You know, we will have worn and and I guess having a few plugins that still need to be adapted to be usable uh a new Will be kind of a detail, I guess Yeah, I'm happy to be challenged. So anyway, um Joe or Felix, do you want to give an overview of just to keep time in mind? I mean Do you want to give an overview of the kind of plan we've got for Moving towards the UX at high level Sure And at a super high level, right? We have what's laid out on screen there So this this first our initial investment or initial investigation here is around a css based visual overhaul So this would not be solving a lot of the fundamental usability challenges that we encounter in Jenkins right now This is actually more about updating the aesthetic of Jenkins Making it look more modern, which as we know does actually impact and improve usability But it's not about solving those deeper issues just yet When we are able to to successfully roll those roll those improvements out We can begin investigating Fixes and improvements that are more fundamental to Jenkins that long-term architecture defining that strategy and working toward that which I personally expect will take us, you know, a good a good amount of time This is going to be a lengthy process But the idea is that We can improve the aesthetics and at least have Jenkins look more modern feel more modern And therefore be a little bit easier to use In the meantime with phase one Yeah, definitely The that we will try to make sure so and we expect that Well, we do is we are we are going we want to maybe err on the side of caution We want to make sure we want to learn from our previous mistakes. We want to Be innovative try to not break stuff and And yeah, we be really careful and try to be Maybe surgical when whenever we try to make changes And this is something when I want for example, this is something That I'm going to mention. Well, so also about point five We for example, we will try to start working on components That Have no style inputs from plugins. Maybe the headers. Maybe stuff and then move on to more complex stuff So we can start Seeing benefits from the get go And we also want to be releasing often. Maybe we we will make the new interface opting But we want plugin maintainers and people to test And their combination of plugins on the new i as soon as possible to help us catch any Any possible issues which will happen issues will occur a year But we are really open to community feedback and to community and um, if Somebody sees a plugin breaking. Please do report to report it to us We will appreciate it Absolutely and what one really important thing mentioned in there as well is This is all intended to be gradual and incremental We want to improving the Jenkins UI continuously And we know that we're going to need to iterate but certainly we don't want grand reveals That are kind of suddenly result in a lot of breakages and things like that So so part of the purpose of this Recurring call as we will have it for the Jenkins UX SIG is Anytime we want to introduce An aesthetic change within phase one will bring it to to the community via this call and the forums and the other communication outlets And and obviously, you know, like you mentioned feel like seek your feedback And and that will help inform What actually is implemented. Sorry was someone going to say something? Yeah, I just wanted to talk About this process and its relation to Jenkins enhancement proposals So we have for phase one when there are Relatively minor changes. It's perfectly fine to do it without jabs But if we talk about architecture changes or major Changes or potentially breaking changes, then you should likely be a Jenkins enhancement proposal Awesome So it's just for you to keep in mind. So yeah, this special interest group is a great venue for initial discussions and for building consensus But if you talk about serious changes, then it's likely about jabs Yeah solid reminder. Thank you. Thank you Yeah, so I think that's So I mean when it comes to the sort of timelines for this, I think it's also Worth being, you know, cognizant. I mean, I think the css overhaul is probably free to six months of work Defining the long-term architecture will probably Be starting in parallel with this once the css overhaul is somewhat underway We're going to start working on the long-term architecture and I think the complete UI overhaul is at least two years worth of work, to be honest I don't think that you know, I don't use any quick fix here. It's available and I think I mean, I'm doing my best to make this as clear as possible to my management Here, of course, you know wanting to get results in three months or six months and not saying, you know Two to three years, but I mean, I think just the reality of this type of projects and I've been through This on a number of products before in my life both as a developer and a project manager is that it Takes much much longer than you think and There isn't really a very good way of speeding these things up a lot either. I mean It can be obviously I think things like the plug-in work or some work can be parallelized, but It's not very easy to get 120 people and to give them all, you know One little widget each and then it's something great to come out of it again. It'll measure your work together One comment slash suggestion for this specialist group There are already some plugins which I intend changing Jenkins themes For example simple theme plugin for which there are dozens of Public themes in open source and some themes are really good basically they use existing Jenkins Structure and they and just apply new css or javascript And it's a kind of existing engine which you got a lot of adoption So for phase one, it might make sense to just take a look at the existing themes and maybe well just uh Speaking of laundry we can take one of theme Jenkins commune to likes and replace The default thing and just create a classic theme for the existing UI. So yeah, it's freeze one. It might Yeah, it might see if you sometime. Yeah So that's perfect because that's exactly what People already have proposed. So I just missed the 30 minutes. So yeah No, no, no, I mean it's been discussed here and there for a few times. Obviously it's been, you know one Obvious thing like trying to basically Make Jenkins default Jenkins behave more like Some good things Inside the theme plugin, but maybe I'm going to actually leave Joe Discuss this a bit more because he's the UX expert here So we will probably have more to say around the potential improvements that we can do on Jenkins itself So I love the efficiency of the idea, right? Um, but there's a bit of a danger there too where We don't want necessarily to just be picking up themes or themes or styles that currently exist because In the long term that sort of can inhibit our ability to form a proper design language for Jenkins So additional components that we're redesigning and implementing in the coming months throughout phase one will have to be informed by the design and style choices that have been made for those themes And that's not to knock those themes at all. Um, but but it does it does sort of restrict The uh the ability to create a unique design language and an aesthetic for Jenkins That that could affect sort of the overall cohesion and I'd hate for us to be in a situation In the future where We sort of stepped on our own feet in that way, even though it could save us time up front Yeah, we think about things that the most of things just don't have any design decisions because they're basically just a css replacement Uh, there are some javascript based themes for where it's quite different Uh, but yeah, that's why I mentioned it as a potential because it's exactly please one You mentioned without any other such changes Yeah, and I think the phase one, uh idea around making purely high level like simple things Changes, um Is a good thing or so because maybe you would create um, you know desire Uh traction from the community to see, you know, Jenkins is already evolving already changing phase already being Nicer and maybe we would have more people from the community actually come here and then we can, you know enter deeper Uh, surgery changes and everything And the simple thing plugins from my understanding from them is that The themes are a special kind of community Items that is really difficult not to break Maybe not in this first phase but the plugins are The way the plugins define the css is tightly coupled to the html generated Yes, so this tool you will break themes and I would say that uh, don't let it stop you Yeah, I mean Yeah, sorry, please can you can you Yeah, so themes are really tied to the current css and of course you cannot move jink is designed forward without breaking them and Jenkins project doesn't define any compatibility for The layouts and for the structure. So basically even now in weekly releases we are free to break The structure of layout as much as we want So obviously we don't want to break it just because but there is no practical restrictions And yeah, I understand your concern and I just don't think it's a real obstacle for please to Yeah, that doesn't mean that we are going to intentionally break them. We will when possible and we when it's I don't know When possible we will try to walk around the existence of of the themes I'm actually being inspired by them, but yeah, thank you for pointing that out So when it comes to actual stylization and aesthetics of the UI like creating a you know defining a color palette and the typography For example iconography throughout Jenkins all of that stuff will will be created Um from scratch to so that we can eventually have In the Jenkins design language that's consistent rather than picked up from a current theme if we can utilize some of the Infrastructure and some of the code that that goes into Making themes possible. That's totally Sounds like a great thing from my perspective But but as far as stylization goes we want to build this right and create it from scratch in that garden I might be I think I'm on a slightly different topic than the rest of you, but I just wanted to clarify that With somebody's thinking something I think you're kind of distant there I Think everybody should have access to the document now. Sorry. I didn't get that set up quite right, but Yeah, some there was some noise in the background. I don't know Anyway, maybe not some maybe not somebody trying to talk maybe in the background of Oleg or something Maybe uh, I'm on the loose now Yes, Swiss people are very noisy Well, it's not Swiss people Yeah, and you know him pretty well, you're a French speaking one Somewhat Okay, maybe we we can now we are talking about plugins we can talk about Sort of the development process which will be basically based around breaking a few plugins as possible So We are going as I mentioned before we are going to be prioritizing changes based on Different priorities for example whether removing Some piece of the UI can help us free and remove a library after making sure it's not used by plugins Secondly trying to change we will focus on changing stuff where we can Where we are confident UI elements that have no contributions from plugins. For example, maybe headers or breadcrumbs versus the config forms the config forms are Those are more delicate and we will also A concern we have something we will try to avoid is um having We will we want to minimize inconsistency in the UI where The new elements clash officially with The old elements on the page so We will probably iterate it's going to be it's Probably we are going to do several iterations Maybe we start working on the header and then we revisit the header in a few months from now once we have More updated more UI elements So this is the way we thought we were going to prioritize the plugins. Is there any input about this? Does anybody have any suggestions? Only one thing For serious changes is about REST APIs. So what I do not see in the current plan is what would be the architecture of new UI Do you include a major rework of the Jenkins APIs in this phase? Or do you want to build the new UI on the top of existing APIs? um I think this is a really good question that obviously we're going to be Defining during the long-term architecture, but I mean, I think it's good that we talk about it now because I mean what I mean, I think these are exactly the things we need to decide. I mean, in my opinion We need to have a full new UI for Jenkins That's a modern UI that's based on, you know, the clear separation between front-sending back ends And for me one of the goals of this is that Elements of the UI should be embeddable inside other products, you know, so that you can for instance To name something controversial inside of GitHub actions We should be able to show, you know, a little bit of a Jenkins pipeline or, you know Inside the flow product that CloudBeans has just bought to make a more commercial example We should be able to show a little bit of Jenkins UI You know, it's definitely doable. So we think of it. It's not how the current Jenkins UI is designed Yeah, the most of Jenkins front-end except a few plugins like warning spotting in by Uli and The similar ones, they use server-side generation of pages So what you need to keep in account when you work on this project and that for many things there is just not No REST API And basically in Jenkins you don't have a documentation for REST API, so you just have to look into the code. Yeah, there is a JSOC project for generating open API or Schwagger Uh, but it's not yet implemented Yeah, I think the current Idea that really there there would be a phase one at least or something like this Whatever we call it that would be more around what we we've called somehow CSS only changes But like trying to have, you know, kind of high impact in a very short term trying to fix What is Maybe not only low hanging fruits, but things that are of use and you know, that would at least first, you know start fixing things that make Jenkins You know look like old at first sight and I think we can do have an impact on that in a very short term and then As Jeremy's saying, I think the what Jeremy is referring to in like two years long plan is indeed trying to do As we go get getting bolder and bolder, we get good traction. We get people You know complaining Being happy We try to see what we can do what is succeeding what is Breaking everything Trying to maybe release and only bases very very trade iterative. So we do we avoid blowing up everything, you know after very long tunnel so, but yeah I do not see so to in other words, I do not really see the rest api Uh as the very very first thing we need to do but because to kind of start having something like, you know being visibly initiative that's convenient back, but yeah in the midterm Short short I think it does make a lot of sense Yeah, I'm pretty sure whether it's possible to build it. I mean if you're gonna have a ui That's ultimately based on rest api to properly need to have that api up front Yeah, that's why I would rather think about freeze to not freeze because long term architecture Is a definitely ways the way you define the new concept I think it I think this is something that maybe I eat a bit too early talk now maybe because there are Many ways there are definitely more ways to improve jenkins ui Make it using more modern tools that they're aware Three years ago four years ago when blue ocean was created um Um, there are more use technologies that said I think it's something that really really warrants high level of research That I think that's what this said a our Our first effort will be focusing on Doing Low effort or a low step for possible high impact visual changes While planning for the for the other stuff, but not necessarily Focusing on the actual planning Just put the suggestion because it's not necessarily Yeah, what I mean that basically it's unlikely server side think anymore Yeah, what I mean, I think the key thing is there's a separation You know between Then not one method you are So I mean one result this could be that we're having hundreds of different sub UIs Part of you know companies I don't sort of overall You know A monolithic, you know thing either it's a part of the whole chain, you know dev ops and People will want to visualize that in different ways. I think it's important So this is possible. This is important key objective of this new ui work is that you know We're not just thinking about Jenkins as a standalone thing anymore Think bigger than that Looking at the time we've got about 10 minutes left And I'm I'm pretty sure we can talk a lot longer, but I just wanted to First of all touch on the topic of How often should we do this sessions then? And the people think that they're valuable should we do it every two weeks or should we do it once a month? What's the format of this session is this working while we've only done it once so maybe it's a bit too soon to say is it working but Just any feedback about that anybody can speak or comments My personal inclination is that we would it would be good to start off doing this as a monthly call And then we can certainly adjust to make it more frequent if we if we want to But that's just my two cents All right, so that's tally monthly or two weekly. I think is the two options We have one vote for monthly. Does anybody else want to vote monthly? Yeah, I think I agree with that approach. Yeah For me it's good I assume if if you're communicating if we're meeting monthly that means there must be a very much communication outside the meeting Yeah Yeah There will need to be I don't I don't think that's set up yet mark But yes, you're absolutely right with regards to this sig It shouldn't just be a monthly update The this call would just be where we did do the most discussion face to face so to speak But yeah, we got a set of other communication To be honest, I would rather have a more Frequent call the shorter one. I mean we are doing continuous things, right? So and so Having a 30 minutes call every two weeks instead of one hour every month. I think is slightly Maybe better to keep the ball rolling the balls rolling, but I'm fine with whatever people think Would be better at this stage. You know, we're still getting started So, you know trying to impose some some rhythm is maybe better at this stage at least but just me I agree with that this I and I believe that if we do it monthly We will make the risk of just doing demos While doing it two weeks once every two weeks It will make discussions easier Yeah, my feeling is that we need to get a rhythm going and I also feel that If we do two weeks, it's okay for people to miss a session or two if it's monthly and you kind of miss one or two sessions Then you're almost out of the game It's a good point Here's a moment of jack right I'm this is Carl. I'm a plus one on every two weeks. It would make it that much less likely for me to forget Yeah, sounds like we got an answer Works for me We can always iterate if we need to but those are all really good points. So sounds good Okay Anything anybody would like to discuss in the last five minutes. Yeah, I would like to ask something which is Ideally we want to To work soon as I'm not somebody mentioned There's still bound to be offline communication So I was going to I was going to suggest maybe we can We start thinking about our proper feedback channels where we can propose UI changes Yeah, actually, uh, so I think it was already proposed by Oleg and and it does make To reuse the gen keys dash UX mailing list. That's already existing, isn't it? And there's even your IRC channel. Even if that one probably is Getting instructions nowadays But yeah We already got IRC chat could be just moved to Deter or whatever though. I'm not a big fan of Deter either Is it possible that we can create a slack workspace? Um, maybe could create slack worker space in the continuous delivery foundation. Uh, so we had a discussion with CDF And we can host project channels today if that is interest Um, so if somebody wants to try it, uh, you could do that But yeah, for the record right now, none of our gen keys resources is Hosted within a slack and there are strong opinions from some contributors about slack so All right, what are the strong what are the negatives about slack? It's commercial company, I guess. So yeah, something like that But yeah, basically it's up to the special interest group to define a channel which is Which suits the special interest group the most So personally I don't care because I'm in cdf slack anyway Uh, it's maybe a question for team for woolly and for the people who are not in cdf slack I would prefer slack Anybody have an issue of slack Will you unmute it? Uh, I've never used it. So Pretty easy Pretty easy Yeah, I have a lot of fun on your machine But yeah Can wipe it up Yeah So should we try I mean obviously people can reuse the Jenkins UX main list exists. I've announced this group on there. I mean, it's not There's hardly any traffic on it So it would be easy to use that but we can try a slack as well. I'm happy to try that Can you can take the action to create that slack? Well, basically anybody can create it in my cdf. You don't need special permissions One thing that you should probably confirm it in the general room before doing so but Any member of cdf slack can just go ahead and create a new channel How do you how do you join it? I'm on the website. Can't find a link to slack I just second I'll find the Anyway, I think we can handle those things. Maybe I synchronously with actually more. Well, maybe we have more people complaining but For more visibility in the end on Jenkins there for now or even Jenkins dash UX and You know pinging people about the fact that we are switching conversation on Jenkins dash UX main list for now My personal preference is that I do not really really mind about the Instance messaging channel we would use but I I am not a huge fan of using such tools for asynchronous compatible messaging and discussions like instead of many in it But yeah, that's how People do that nowadays Sorry, do you know if the cdf slack is paid slack or is it Adjusted shift. So right now they have one southern messages Used so you have a man's southern cleft, but after that interesting things that will start happening Yeah, yeah, there's also that yeah It's just for people that don't understand Free slack at some point your messages will start rolling over so old messages. So it means that it's only ephemeral Maybe less than ideal or we would pay I don't know. I'm not sure Jenkins Jenkins project has budgets for paying Reds or thousands of euros or dollars for Well, it's another question to cdf They declared to intent to deploy slack But yeah, yeah, right. I'm not sure what's the plan about switching from the price account there Yeah, we should research Yes to ask basically what we do when basically the communities are losing their messages And you know the The most the more active a community is the quickest the quicker that thing is going to happen. So it's it's probably not great Yeah, maybe we had a discussion about deploying much or most or rocket chart or whatever in infrastructure team, uh, maybe a couple of weeks ago But again in bolus dying to meeting people there and setting everything up Yeah Worry about it when we get closer and it kind of gets down to a what sort of discussion. So you're having there Do they need to be there long term? Yeah, exactly, but you know, there's always I see a way the matter kind of, you know A drift about that saying it's only temporary Like like messages related to things longer term should be happening there, but that's not what I'm seeing all the time Anyway, let's get that son of a son reagan out of time. So Uh, that's that's pretty something we can discuss, you know, asynchronicity or even with wider audience again In anything I guess Jeremy I guess we can call the meeting out or something. Is there anything else related to the core Intent of today that that someone would like to raise what you think like I guess team and uli mostly and because uh, I mean the Some some if not all of the others were aware of that thing and we would really love to hear what you think Actually, I don't understand the question I mean, I'm what I'm saying that I guess the main people I'm interested to hear feedback from is more like so you and team more than the other people in the call because uh we don't I mean The people who are not working for clad basically Yeah, I think it's quite important what we are doing here. So we should continue. Yes I just just keep the message and going I guess See if we can get involved and we uh, um can try things out as well an experiment Thanks, I need to drop. Thank you everybody for joining I hope this was valuable and I'll arrange something in the next two weeks and announce it on the public same time in two weeks Thank you, everyone. Thanks everyone. Thank you. Thank you. Bye. Good to meet you. I'm Cheers. Bye. Thank you