 Now I'll share again. So, hello everybody, welcome to the second edition of the Jenkins Youth Experience Special Interest Group. Hey Jeremy, I think it's not sharing right now for some reason. No, I have to reshare so let me do that again. So, let's just do a quick review of the agenda. So, first of all, anybody is welcome to suggest topics. So, if you want to, please go ahead and interrupt me. But I think since this is a fairly new SIG and I think Alex, this is the first time you're joining it, it'd be good if everybody just does a quick round of introductions. So, we know who's who. I wanted to give the quick updates. Rhys and I made a statement about Blue Ocean on both on the developer's mailing list. I also repeated that statement at the Jenkins Contributor Summit at DevOps World, Jenkins World. So, I'd just like to spend a minute or two on that. Then over to Joe. Joe's been talking about the CDS Slack channel. Some of the documents he's created to attract some of the resources. Felix is going to talk about the UI revamp strategy. Then Joe's going to show a little bit of his designs in his processes. Felix is going to talk a little bit about replacing the internal JS built tool with Webpack. And then seems to have a Google Summer Code project idea from Slayden Means. I think Alex just added. Anybody else want to add anything for this good? I think it's good if we can just post all these topics. Let's just do a quick introduction because Alex and Slayden both went here last time. So, my name is Jeremy Harkley. I'm the leader of this special interest group. I'm also professionally I'm a product manager working at CloudBiz. I'm responsible for Jenkins and for the CloudBiz Jenkins distribution. Within CloudBiz, the foundation team, which is one of the main engineering teams working on Jenkins and the security team all underneath my product management. And, well, one of my special interests is replacing the Jenkins year acts. I mean, it's been my goal since I joined CloudBiz and I'm really happy that it's slowly starting to move forward. So, I'm going to ask the next person would be, my list would be Felix, if you could introduce yourself. Hi, I'm Felix Keiruga. I'm a front-end developer in CloudBiz and I will be the developer from CloudBiz that will be implementing and aligning with the community on the new UI changes. Okay, George, next in my list. Hello there, a couple of you I've not met before on the call today. My name is Joe Brubin. I'm a product designer at CloudBiz working on Jenkins and I think that's about it. I'll tell you a little bit more about what's going on in the slides later on in the call today. Nice to meet you. Okay, Oleg is next in my list, please. Hi, I'm a Jenkins core maintainer and recently joined Jenkins both. So, my personal interest is to improve Jenkins UI UX and to ensure that it happens as monthly for current plugin maintainers and Jenkins users. So, that's why I joined this special interest group and I tried to follow it as possible. Alright, next in my list is Ivarista. Hey, hello there. I'm Ivaristo. I've been a software engineer in CloudBiz for around three years working in the foundation team with the team working in Jenkins and I've got a past as a front-end engineer as well. So, that's why I'm interested in all this as well. Nice to meet you. Next in my list is Adrienne. Hi, everyone. So, my name is Adrian. I'm working for CloudBiz for five years and been in Jenkins community for almost 10 years now and I will be joining on this effort in CloudBiz to improve Jenkins UI. Okay, next my list is Parker. Hey, I'm Parker and product marketing work closely with Jeremy on all things Jenkins and the proprietary CloudBiz Jenkins solutions as well. Alright, next in my list is Slaydan, if I'm pronouncing that correctly. Yep, perfect. So, I've actually I participated in the community bridge project with Jenkins. So, I'm a relatively new developer. So, I by making this voice to come in maybe try and help with the UI UX of Jenkins. So, that's why I joined CSID. Hopefully, I can contribute and make a difference. Okay, great. Welcome, everyone is welcome. Next in my list is Alex. Yeah, my name's Alex Earl. I've been involved in Jenkins for some time. I'm mainly here as kind of just an observer. I was recently elected to the Jenkins board. So, I'm just kind of trying to understand what all the different CIG groups are doing. Yeah, congratulations on that, Alex. And thanks for telling us. The last one I've got on my list is Carl. Hey, there. My name is Carl Schultz. I'm out of North Carolina in the US. I am a software engineer at CloudBiz working mostly on pipeline stuff and have had an interest in the the evolution of the Jenkins user interface and user experience since joining the company and becoming involved with Jenkins. Okay, did I miss anybody? Bit hard to track on soon. Nope. All right, well, it's great. We've welcome everybody. So, just very briefly, because we've got a lot of points to cover, but I think the week before last, I made a statement on the developers group about Blue Ocean and the status of Blue Ocean. So, for those that haven't read this, I mean, the statement basically says that Blue Ocean didn't reach its original objectives. So, the original objectives of Blue Ocean was that it would replace the whole of Jenkins UX. Whereas in reality, it managed to create a pretty good UI for visualizing Jenkins pipelines. It did a reasonable job of making it possible to develop basic pipelines in UX, even though that was limited, but it never managed to spread out from there and start extending across the whole UX. So, the main reasons for this were partly changes in cloud view strategy and changes in resourcing. And secondly, the fact that the fact that extensibility wasn't tackled to start with and obviously ran into issues once it moved out of pipelines, had to deal with the fact that there were lots of plugins out there that could all contribute to a little bit of UX. So, the current status of Blue Ocean is that at least as far as cloud business is concerned, we're not developing this further. We are maintaining it in the sense that we'll obviously do security fixes, we'll do bug fixes that are high priority, community PRs that make sense, we'll get merged, we're planning to do a release of it hopefully once every month or so with fixes, but no major features will get added. I made a similar statement at the Jenkins Contributor Summit and at Jenkins World as well, because that was the next week and I also talked about the new UI project, which is obviously the subject of this SIG. I think some people are quite worried about Blue Ocean going away, but I think people are happy that a new UI is being built, however, and I think it's important to be clear that Blue Ocean will remain in place until something is there to replace it, so it's not like we're pulling it out of the project, we're just not building new functionality on it. My feeling personally is that we have pushed Blue Ocean very hard, so we need to at least maintain it and keep it alive until we're ready to replace it. We can't simply pull the plug on it just because it didn't achieve its objectives. I think it's reasonable that we stop investing strongly in it, but we need to keep it functioning because most of the training, a lot of the images, whatever, all based on Blue Ocean. We, at least as Cloudies, have no role to play there. Any comments on this or silence? Okay, so that was my update. I mean, the nice thing was in Lisbon, a lot of people are very enthusiastic about the new UI. I'm happy to hear that things were moving forward there. Big things were still happening in Jenkins, so that was good news. All right, over to the Section 4 General Miss. Joe, you want to go ahead? Sure. Hey, good morning, everybody. For those of you that joined after I said this earlier, I'm a little bit under the weather, so if I have to sporadically pause and sneeze, don't take that personally, please. But hi, everybody. A couple of items to move through here. Just since this is our second instance of this SIG meeting, just some housekeeping stuff. Item A there is that in the previous call, in the first call, we had a consensus that we would have conversation in between SIG meetings in the dedicated Slack Channel, in the CDF Slack organization. So if you scroll up in this document on screen, which you don't have to do right now, Jeremy, you'll see notes where we sort of came to that conclusion. Unfortunately, Slack doesn't allow me to go and send a direct link, at least not that I've seen, to join that. So if you just shoot me an email at jbrugan at clubbies.com, I'll get your added right away. No questions asked, and we'll get everyone in there, and that's where we'll host a conversation between these meetings. And then Item 4B there. Could you open that one up real quickly, Jeremy? Yeah. Item 4B, I was trying to send a screenshot of the Slack, but it's a very boring Slack at the moment, because nobody's in it. Yeah, I just created the channel a couple days ago, so no one's there yet. That's where we'll host our conversation moving forward though. So what this, awesome. So what this document on screen is here is, we know that we're going to have these meetings, they're currently scheduled for every other week. We're going to have our conversations in Slack, but you know, things can get a little bit messy with a bunch of different locations for communication in the community sometimes. You know, we have mailing lists and we have our Slack channel now, we have this and that. So this is one document where all resources that are created in relation to this project will just be listed in this document. I'll throw this in the Slack channel as well as the topic for the Slack channel. So anytime you need to reference anything related to this SIG, it should be linked here. Meeting agenda notes, Jenkins UI revamp document that we'll look at in a little bit, a header bar with breadcrumbs design that we'll look at in a little bit. As we create more stuff, we'll put it on this document. So very simple resource, that's that. Let me close this, and then you'd like to, or we're going to move on to the Jenkins UI revamp over here, which is Felix's one. Yeah, you want to speak to that one, Felix? Yeah, can you open that up Jeremy, please? Yeah. Okay, so we've created a document where we summarize basically our, what our approach will be to the project, what we consider it on scope, out of scope. We have also done some technical analysis, and we listed some of the difficulties we think we are going to have. We did every analysis on the current state of CSS within Jenkins. We listed a bit of the problems we think we are going to have with plugins. It's a high level document. It doesn't go into really, really big detail on any topic, but it's definitely a guideline. And if anybody, I encourage everybody to take a look at it, read it, and if there's something that seems of any feedback on the strategy, any feedback on any point, please do tell, create a full comment, and we will discuss it. For some of the examples I mentioned here is, can you scroll down a bit? For example, here I say a bit down. Yeah, for example here, plugin impact, at least we, for example, we have a section dedicated to issues, possible issues with plugins, which problems I see that can happen with plugins. It's more of this is going to happen. We need to decide what to do and basically also a way to raise a discussion of how to approach stuff. Is this document public? Because if so, it would be great to get it linked. It's public. Everybody can comment on it and add suggestions and it's linked. There's a public link on the both on the order of the day, on the meeting. Oh yeah, I see it. Yeah, and also on the Jenkins SIG resources that Joe just created. If you want, I can go into lots of detail about all the sections on the document, but I think it's better if everybody takes a look at it offline because we are quite packed into now. Okay. That's a really awesome resource for this SIG as well. Thank you. All right, so should we move to point five, which is the first actual designs we're going to see. Sure. Yeah, if you could open that slide deck up. So for a little bit more context on this, something that we want to do ideally in every one of these twice monthly SIG meetups is present a little bit of design and the redesign of a new component within the Jenkins interface. And the reason we're doing that is because this is what while these components are being actually designed and implemented as part of a cloud beast project we're leaning pretty heavily and we'll really cherish community feedback to inform these designs and of course how we implement them. That's why everything is being so being done so openly here. So this first deck is a little bit pedantic just because this is the first time we're doing this there's a lot here and I won't redo everything at this point. Of course this is all linked to be on all those in all those locations for you to check out. But let's go ahead and do that with slide two. Let's jump in there Jeremy. So just laying this out because I figure probably the vast majority of people who will look at these things won't be on these calls right so this is what the SIG is setting the expectation for these. Hopefully we'll have one of these every other week as you mentioned and each one will focus on one component within the Jenkins interface sort of outline some of the design logic that's going into that component's redesign and then details about how and where to provide feedback. The takeaway from this slide is Jenkins is excuse me clubbies is obviously working on a visual refresh of Jenkins and that's yeah that's that's the overview here. We'll go to slide three. Since we have so much to cover in today's agenda which is awesome I'm not going to redo every single thing but there are some valuable takeaways and survival notes in here for you to reference after this call. Thinking about how the Jenkins brand will continue to evolve through the interface through this redesign specifically and how it relates to the cloud based brands. These are two very distinct brands as they should be. The goal of the project of the of the CSS refreshes is not to bring them any closer together in fact it's to strengthen the independent Jenkins brand and strengthen the Jenkins product and improve usability of course through the design. We can jump to slide four I think and then a couple of really important points here as well in addition to introducing a really modern interface in Jenkins for everyone who uses it in the global community here we also want to improve basic visual accessibility. There are a lot of excuse me there are a lot of interactions inside of Jenkins that suffer from poor visual accessibility could be made a lot better with some various straightforward tweaks so that's a priority in addition to making things look better and therefore feel and therefore be a little bit more intuitive they will also be a little bit more accessible and follow more modern web standards for visual accessibility. Yeah I have a question about that so we are in the progress discussing one potential JSOC project which is about mode for colorblind people. Would it be something interesting in regards to this topic so I mean when we design the UI etc supporting additional modes to improve accessibility for particular purpose of people who may have different requirements? Yeah so sorry Oleg it's a question sort of do we want to pair up resources on these two projects or certainly we should be creating both to the same accessibility standards right but can you can you clarify the question sorry. Yeah so if this project happens of course it will be coordinated in the seek and I would be happy to get more contributors involved but yeah I think about accessibility is whether you assume that there will be additional modes because we're going to have one mode for colorblind people because colorblind just needs specific requirements which we would need to deliver. Yeah I thought right now is oh sorry go ahead somebody else now jump in. So one of the points I say in the strategy document is that it's not the scope of this project to provide a certain level of accessibility. We are not going to say well okay we are going to have a double A interface no we are just going to assume as long as we work on components we'll try to improve it. For example one of the key items for accessibility for people with different I don't know color impairments I don't know what the proper working English is sorry. With the difficulties perceiving different colors is that you don't for example you don't have you don't depend on color to convey a state for example you don't just change the color of a button whenever you hover onto it you you make another effect, a transition, an animation, underlying a link that we will take into account. But we are not going to target a specific level but yeah we still welcome if there's this other project for color, improve colorblind support please we can put those people in contact with us. Yeah so we won't be able to solve all accessibility issues certainly within the scope of this project however whenever we're redesigning component just to reiterate whenever we're redesigning component we have that opportunity to make sure our typography our color palette is accessible wherever we can we will we will fix and improve accessibility in that regard but it won't be a total overhaul yet you know it's something we need to work toward. Yeah that's perfectly fine and yeah if we just retain the same level of extensibility as it's available in the current UI I guess it would add the rest of the story anyway because somebody would be able to apply a custom theme and that's it. Can you repeat that last bit so if we retain the same level of extensibility like we have now so one basically everybody can replace css and add additional javascript to Jenkins web interface and basically redesign it entirely if needed so if we retain these features after the redesign I think we'll address these keys. Yeah certainly the intention is to maintain as you say maintain extensibility as we're redesigning these components we're starting off with a slightly less complex component which we'll look at in just a second but yes that's that's part of the goal here for sure. The second item on the screen there is just a note about working toward a Jenkins design system. It doesn't have like a formal name yet because we don't need to need to be confusing anyone thinking it's a different product or a different project or anything like that. It's something that'll be built organically as we move through component designs. I think we can jump to slide five. So real quickly just to address all that I see you have a comment there this is Jenkins design language v2 so there was a and still is documented on the web the Jenkins design language which is slightly before my time at CloudBees but from what I understand an initiative to create a design language a design system of sorts based on the Blue Ocean interface. Obviously following you know Jeremy's update there about the future of Blue Ocean and CloudBees' stance toward it and how we're maintaining it moving forward yes this is not a v2 but this is a different initiative just because we're taking a different approach with this project so when you see reference if you do to Jenkins design language around the web that is separate yeah just to clear up any confusion. Yeah right and probably we should tear down Jenkins design and advantage resources because we even have your website sorry we even have GitHub by your website for it if I recall correctly. Yes I agree that that should be. Sorry about that also you may see also on the when we refer to the scope of what we think the project should cover on the strategy document where we would like to be able to provide a place like a sort of storybook a place where we could list designs components develop those in isolation so people could see all the components separated without going to the Jenkins instance. This is not something we can commit to do right now it's something that we would like it may happen but it's not even we are not sure it's we are not saying it's going to happen it's something that it's a possibility but our focus is to deliver changes to the Jenkins UI and move towards a design system but not to create the design system or focus is delivering the UI changes. Yeah so so to to clarify and I think we're on the same page there Felix right when I say working toward a Jenkins design system it's not to say I'm a designer promising you that you'll have a design system to reference starting tomorrow or anything like that it's just to say that as we move through these design improvements we'll be thinking about them cohesively as part of a larger system of sorts which isn't being formalized right now but that they will be design decisions will be intentional and component designs will relate to one another so that they feel like one cohesive system but no we're not we're not creating or shipping anything like that at the moment no. Yeah that's perfectly fine. We better jump to slide five there for time sorry so I mentioned that we're sort of starting off small this is our second SIG meeting ever and the first design that we want to introduce for feedback here and keep in mind we can we can do feedback in the call here that's totally fine but we also have our select channel and feedback is welcome anytime after after this call as well. The first one we want to look at here is the header bar with breadcrumbs so throughout the course of this visual refresh really this is CSS centric and therefore functionality will remain largely the same this is about aesthetics right now but this will allow us to do to achieve some of the stuff we mentioned earlier like improving visual sensibility with a new color palette modern iconography things like that so just running through these bullets here mention this is a fairly straightforward choice for our first one not super controversial because this one since functionality would be remaining largely the same won't really have too much impact on user workflow and won't have too many plug-in implications and impacting people's day-to-day right off the bat so slightly less controversial but you know let me know if something let us know if something stands out as problematic and and you know this is the sort of cut dialogue that we'll go back to inform the design of course. I mentioned all colors in typography since we have the opportunity to do so are being measured by modern visual accessibility standards even though we're not you know fixing Jenkins accessibility for lack of a better expression right now there's an opportunity to do that in small ways here so we're taking advantage of that this this component and other components in future SIG calls that we share are also being designed to scale down well to mobile. I don't have that for you this week and I'll share that in the next sync alongside some other designs and really this is this is fairly straightforward we're looking at a few states here so on the very top page they're looking at just our Jenkins landing right if you're if you're brand new into the interface for example very straightforward everything should look the same or excuse me everything should work the same way but look slightly better in that middle screenshot there we got a comment coming through I'll look at that comment in just a second in that middle screenshot there we have the autofill autofill selection state for the search bar so you see that the selected autofill item this is a slight tweak here in addition to the very light color fill that's applied to each item as you sort of excuse me as you sort of scroll down through that list you also have a little icon indicator on the right there this is a comment technique for autofill lists like this in modern ui is to improve accessibility and then some minor adjustments to how we do breadcrumbs as well although the logic of breadcrumbs can certainly be improved that's a bit out of scope for this effort right now so again just visual improvements at the moment and again this is a fairly straightforward one you know in future weeks and months there will be designs we introduced for additional components that are going to be a lot more controversial a lot more confusing potentially what does this mean for my workflow what does this mean for xyz plugin and that's where we're really going to get into the meat of of conversation i think but your feedback is and i speak to everyone of course feedback is more than welcome here and in slack after for this first component let me see there was a chat yeah that's just me saying it looks good okay thank you cool it looks simple clean that's the goal that's certainly the goal a lot a lot of room for improvement but you know we we want to be very intentional about how we go about improving these design the design elements by piece anybody else may have one question about the technology under the hood of new ui components this summer we had a pretty successful google summer of course project which was devoted to working hours plugin during improvements and basically to was using craft and include standard libraries intelligent plugin to have some controls etc what is the current consideration for this project do you want to use existing technology or do you want to create something from scratch dedicated to junctions feel it's something you could speak a little more to yeah maybe this question is too early but yeah it would be nice to know if there are any additional insights or plans about the tech oleg hi oleg i sorry but i don't think i understood your question uh do you do you mean if we are going to add existing css existing css classes or or add new ones add new files remove the old ones since this part is quite fine uh joe was talking about creating new controls so i just wanted to understand what is the plan for new controls do you want to use standard ones from libraries or do we want to create our own ones uh just you meant new controls yes new okay right now we want we don't want to touch any new javascript at all so for example here the the search autocomplete widget is i think it is on using jacquo ui it's it if if it's for me it's going to to still be the same i agree we don't want to touch any javascript at all if it's not 100% so in that regard the control would be exactly the same we may add new css classes to it to style it or we may even style it through the yahoo ui classes but we we are not going to uh alter any behavior or program the search bar again is that good does that answer your question sorry i wasn't ready i might have misspoken the oleg if i was talking if i was talking about different controls yeah this is definitely all about all meant to be about styling and even looking at at that automatic refresh toggle there right that's something that uh just in the past uh day or so if you like said you know we've been talking about it and we've said that you know that's probably not the best way we should probably just since this is css focused just maintain a text link and so that's a piece of the design that i will be updating and we'll share back with you all yeah regarding uh regarding that i believe that it will be removed soon so there is a pendant yeah that's true project by daniel beck about getting rid of that i heard that yesterday as well yeah and so and so that's great um and and i will be updating the design to reflect that said oleg if if there's any yeah and that's the point one of the points of these meetings if you think there's any project or ongoing summer code project or something that we are changing you of these UI controls do tell us and we will look into it and we will communicate as much as possible with the people working on those changes of course yeah all right so in the interest of time one more quick comment from somebody else on this or should we move on we'll come more fast i guess okay so providing feedback again like we said there's the uh these continuous delivery foundation slack is a great way obviously you can also do this in whatever other possible way but best if we centralize it in the slack channel or if you can't get there then the Jenkins user experience main list yeah i hate to make you all email me to get into slack it's just slack won't let me do a direct link but obviously no questions asked email me and i'll throw you in there and we'll go from there all right so thank you joe um next point um let's quickly do the replacement of jazz builder with webpacks deluxe then we start time to the other point so no more than five minutes please no no i'm just going i'm not even going to to share anything visually or more code um Jenkins uses uh well the Jenkins ecosystem uses a tool called js builder uh well a family of tools called js builder js modules etc to us the way to build the ui elements uh sorry for the ui assets say javascript cfs and stuff like that uh some people have expressed trouble using that tool those tools are custom are they introduce a maintainability burden and have not the best documentation they also come from from my understanding um become from a time where the javascript ecosystem was not as mature as it is today thankfully things have evolved in these years and now there's there are more industry standard tools like webpack that will allow that allows having an actual build and compilation toolchain for javascript css and evil bundling stuff like fonts spg icons things like that what we are going to i've been working on a proof of concept uh that we that will replace the js builder used in the jenkins core repo important just on only on the jenkins core repo with webpack webpack is the more most more widely used module bundler in the javascript ecosystem right now every frontend developer knows how to use it it has great support it works works like a charm and it allows it will allow us on the jenkins project to add new features really easily uh i will we have a few examples for example it will be trivial to add a typescript to the jenkins project once we replace the js builder with webpack there is also going to be a more immediate benefit which would be um we can start using a tool called post css which is a tool to process css to enhance but but towards compatibility uh optimize the media queries things like that that are right now it's not possible to add to js builder so just to summarize this is a way to re to remove a custom piece of infrastructure on the jenkins project on the jenkins core repo and replace it with a more widely used tool with better maintenance and that will empower us well and the people working on the jenkins frontend to deliver better and more changes basically yeah would like to add some bits to that yeah your evaluation by philips is totally correct uh so jenkins js builder is a historical thing it was originally created for jenkins to do zero when there was new installation manager developed then it was partially adopted in the ocean and other components but for jenkins as a project these components have been always a major part of them because yeah the maintainer of these components from finally they moved on and basically there was no releases for plugins which bundle jenkins js builder components since the very first releases the release flow is not trivial on my machine the builds just fail and if we can get rid of that stuff it would be really nice and we have success stories for webpack we have success stories for pure npm so yeah if we can move forward to standard technologies it would be a huge step forward so i would definitely i wouldn't be missing any of these technologies because even now we are unable to maintain them basically yeah right i will share the poc uh hopefully as soon as i can as soon as long as i'm sure it doesn't break any hd any hd aph suit or anything basically i do plan to keep a api plugins created by js builder because we have something like 10 of them plugins work js builder just builds a javascript package and plugins are free to use it as any other project is and just want to change it on the jenkins core because the jenkins core has the most complex uh setup of javascript on css and it's also where we're basically it's on a project per project basis it changing it on a project shouldn't affect the other projects okay so in view of time should we move on to point seven giggle summer code 2020 slay them or i like this is actually yeah can you hear me yeah i can hear you yeah this was actually more of a question um since jenkins participates in um google summer of code every almost every year so um my question would be that um can since oleg and you were discussing in the previous gsoft meeting just before this one can can we actually put a project for the ui maybe pick a component from this from the entire project and put it in google summer of code so that um any student can probably take it up and implement it so i would like to know your thoughts on actually picking any one of the um any one of the topics that were discussed by joseph and in the slide for example and maybe put it as a project that would be my question i think it's a great idea i mean obviously it have to i mean i i guess giggle summer of code is four months isn't it so it needs to be you know big enough but not too big and somebody you hear the mentor i guess which would be yeah mentorship is the biggest problem because yeah our expectation that they are at least two mentors in the project and it's a pretty big time dedication so we can expect mentors to spend more than five hours per week um during the entire summer so it's quite a commitment but also you can get really good results out but that's why we advertise a gsoft on the jenkins community and obviously there are any thoughts any ideas which would be afforded to a gsoft project it would be nice i think it's a good idea i mean obviously i can't commit that people on my team will do this or but i mean i would say that it seems like a good idea i'm not sure anybody else has any thoughts yeah my only thought is that maybe it is a good idea but if we start or if the project starts working on a refined design so that the people working on the project can start uh to implement it on those design changes but not uh but they don't need to decide the design or that kind of stuff i think that that would be something important yeah i'm sorry go ahead i was gonna say i also agree that it's a really cool idea um i i i'm not sure if this is what you were you were mentioning every so if this is similar to that but i'm thinking anytime you branch out the group um that's uh implementing a certain design it can become a little murky as far as how these designs relate to one another and making sure we're having consistent aesthetics and consistent patterns between them so there might be a little bit of a danger there however i'm i mean personally i'm open to talking about this and even if it's not exactly um implementing a specific component it could be something even more creative that can contribute back to this project in some way but it's got me thinking and i think it's a a good opportunity can someone remind me when this actually occurs the oh next summer of course mention it's sick all right yeah i think it's a good idea let's talk about it it's a huge next summer but regarding project ideas we expect to have them publish in in january or february okay we all already have some project ideas which are clearly related to the ux special interest group for example rest apis which would be really important for creating new uis we want to automatically generate specifications for them then there are projects which are related to user focus for documentation like pipeline documentation generators again they could be a part of these six interest in some sense but if we had some more projects which are really frontend it would be awesome nice so slayden do you think this is something you could bring back up over in the slack channel and and we could get the conversation rolling on that yeah yeah sure definitely i'll join the slack channel and post it thanks i think also i mean my question to oleg baby is how concrete does it need to be does it really i mean is joining a team and working on this performance to they because it has to be a really kind of like a wraps up kind of thing the deliverable and it yeah the thing that uh what you post is a project idea and it's up to students to come up with a project proposal and they expect it to do so so the idea can be pretty abstract one thing is that the final project has to be quite detached so that the student kind of work on that that the failure of this j-cell project which happens doesn't uh uh block any other major stories but the the idea itself is fine so it's not just like join the team three four months and work on seven or eight different things it has to be more defined than that like a final project yes project idea could be fine so you can just come up with something okay there will be this new Jenkins i forgot well okay Jenkins design language to do zero but so let's create new components for that it could be a good project idea for example you just put a few examples of companies you would like to get like calendar control or whatever and then it's up to the students to come up with a more detailed proposal okay yeah but it's not something quite outsourcing so yeah yeah you want to do the uh perfect yeah so let's move on to point eight because we're running out of time quickly um I guess very quickly we can make enough dates we thanks to well suggestion from Felix and then the work of Oleg we now have enough dates to browse and put stability matrix which is really good because we no longer need to support i.e. nine and ten i mean that's the major changes in Oleg yeah that's it there were some other changes but basically in support levels yeah it doesn't change anything in principle because as long as there are fixes which are submitted and which are reasonable they would be accepted anyway but yeah it at least unblocks introduction of changes which would break the capability with all the browsers yeah and i mean just so everybody's aware i.e. ten i nine is out of support and i 10 is going out of support in january so by the time many of these changes land it's quite safe to build them now on i 11 or better okay so let's just move on because we've marketplace for simple theme plug in any objections can you just tell me a bit more what you mean by that oleg seven or mark this line this one a bit more yeah so basically i have one of pet projects is generator of market places for github ior so you may have seen that there are some market places for example for github actions and for other projects and i was just experimenting with universal repository which allows to create these market places easily basically powered by jackal and i have two potential applications for jinx project one is pipeline library marketplace another one is simple theme plug in marketplace so a simple theme plug in would just list existing themes with some descriptions with some links so it would help users to find these themes and it will also add a place for maintainers to put them on the ground of them so that's the idea nothing really complex inside i just wanted to check whether this is something useful from your point of view or whether it's something which would collide with the stories they seek is working on um i i think it can be problematic because it and i'm not saying it would be i'm not saying that encouraging yeah i think it would encourage some ability but right now the current there is there are no like clear guidelines for seeming the jinx interface right now every plugin go does it something they look into they look at phd infrastructure and everything and boom they do they apply changes we are we are going to break themes so i don't know if it's good for community perception that we to buy the marketplace for simple theme plugins which i think can be understood can be taking us endorsing those themes while at the same time breaking the changing the ui causing some of these themes to break that's a potential risk so i think that simple theme plugin is widely used at the moment and for me it's got 20 thousand installs so more i think yeah and for me it would be also a way to highlight potential capability issues for example we could use marketplace in order to explicitly document what is a target jinx version so instead of embracing it for any version and as you said committing to breaking changes you could be explicit what is the current version and then maintain us when they update the plugins they can also update information in the marketplace so that they explicitly see what is the version they target so we can actually turn it around and use it for the benefit of the project you know evolving qi okay yeah i see your point it can work that way i was i i guess i was a bit afraid because now we know we're going to break plugins we probably we're we're really worrying about plugins and if now we need to really worry about themes um how many things do we need to support you know yeah there are threshold a number of downloads from which we started to need to support themes right i think it's uh so now we don't grant you any kind of theme support as we discussed at the previous meeting and i would rather keep it that way and i'm happy to add for proper disclaimers um so uh but if you think that it's something which could coexist i would try okay so that's why i brought up this topic i personally think it's okay as long as we have like caveats and mornings that you know yeah this is changing i mean it would be annoying if somebody contributes a big thing and then two months later we break everything and then they didn't know that that's tough but we need to be quite clear about it okay so maybe once i have a quick prototype i will just shade and we can do it one of the next meetings it's definitely not something i'm going to do tomorrow because it's a pet project and i have two more new pets yeah and a wife and a baby and a day job yeah so we're pretty much out of time so the next meeting would be on the 25th of December which is not great date and the Wednesday after that's the 1st of January so my proposal is that we have four weeks between meetings should we stick to this time which is 1700 CT is that anybody object to uh this the Wednesday January five o'clock CT 11 o'clock eastern is it UTC or is it minus two whatever local time 1600 UTC okay so yeah just to make sure what is the preference because otherwise next March meetings go south so yeah the practice and jakes commit that we do UTC meetings though again everything goes south because people still live in the local time zone does that mean the meeting's going to be later or earlier whatever just a different time that's the problem so yeah but yeah i think that till March it's fun to stop whatever date let's work that problem out when we get so because yeah because i do have a meeting normally on Wednesday i cannot skip from 1800 CT so anyway for now that's the great the next meetings at this time and then i will try and add it to the Jenkins events calendar if i get the right permissions then yeah i can just edit it for you but speaking of that uh special interest groups and jankies usually have sick pages the information about meetings is documented and it's a source of truth okay if you send me a link to an existing one so i can get the structure and work out how to do that so it's just a janky say your slash six okay i'll send you a link all right thank you everybody for joining today i'm gonna stop the recording and say goodbye thank you everybody my opinion year thank you everybody yeah have a good Christmas everybody bye