 It's only a small group today and that's okay. So let's go ahead and get it started. We're already recording. So bear with me here as I share my screen. Give me one second. All right, so a couple of good topics here today. First and foremost, I don't think we have anyone on the call who hasn't been on this SIG meeting before. So I think we can skip this, new introductions. Does anyone have anything they'd like to add? Feel free of course to hop in there and do this as we're discussing. And without further ado, I think, you know, let's just go ahead and dig in. And Oleg, do you want to start us off talking about the hack fest? Yeah, I could do that. Awesome. So yeah, maybe it's better if I share the screen. Sure. Sure, sure. Okay. Give this my screen. Okay, so last meeting we had a quick discussion about your UX hackathon. Well, what we would like to do that after some follow-ups with the SIG, with documentation SIG and with advocacy outreach. We actually agreed that we want to do that. And over, we set a date and we announced the event. So if you haven't seen it yet, there is a blog post on Jenkins IO which basically describes how the event would look like. We plan to do this my screen. Yep, Mr. Yeah, so we have three main tracks at the moment. User interface, user documentation and spread the word. Mostly about user stories, user experience, describing features, et cetera. And for these three tracks, we are currently collecting project ideas. So I put at least one topic for the discussion in the SIG. And here you can see that we are sampling a number of projects including newcomer and the errors, like some features from look and fill updates from our backlog. Also Jenkins accessibility. This is a topic which we described, discussed last time. Other new befriending issues. We also had a few contributors reaching out about the dark theme for Jenkins. So what we need, we start the discussion about support policy for things, but in principle, we want to have it. And there are other projects which are currently under discussion like system grid permissions and basically read on the web interface and plug-in manager credentials, UI, git plug-in, et cetera, et cetera. So this is the current list. This list is moving target at the moment. So we will be adding items, maybe removing some items, updating descriptions, updating JIRA issues so that there will be more information on the list. But this is what we have at the moment. Regarding the event itself, it will be a five-day event. Basically it's hop-in, hop-off. So it's not a hackathon when everybody just starts hacking full-time. Basically we invite people to spend as much time they're willing to do. And we will be also organizing a number of events. And one question would be about presenters from the UI UX SIG so that we could have more UI-related topics covered today. So this is a quick introduction. The event is live. We already started getting registrations. So by now we have more than 20 registrations and the accounting. So we'll see where we get, but I think that we have a good chance of having a pretty good event and facilitating stories in our roadmap because the most of these items are somewhat represented in Jenkins roadmap at the moment. Okay, any questions? Any comments? Yeah, so just to summarize what else we did in order to support this documentation and support roadmap in principle, I submitted a pull request to Jenkins IO which extends the page a bit. So it adds more participants and if you don't see yourself in this list and you would like to join, just do that. So it can be done via pull request. And we also started documenting projects. So now there is a bit more description for look and feel updates, Jenkins accessibility and user interface overhaul. So basically these three items that represent the stories we already have on the roadmap will accept accessibility, which is a new one. One question? Yes. Should we look for issues in, for my plug-ins for instance, which are regarding user interface, small enhancements and mark some somehow or? Yes, so if we go to the current version of this page, so basically everybody is welcome to submit their project ideas and then we will somehow talk to them and show them on this page. So here you can see, for example, there is a query for dark theme. Let me just open the actual version of this page because there was some edits in the pull request. It takes a while, okay. So here for example, we have Girae pics for look and feel updates, Girae epic for accessibility. We also have a general query for new camera friendly issues. And right now this query shows something like 13 issues. I still need to scrub them, but at least there are some relevant ones. So the first thing you could do, you could just put issues for plug-ins there. And here for example, you could just plug-ins and g-plug-in, enable the response of option for all data tables. So it already got there. And if you just create issues, tag them as user experience, UI, UX, UXC front-end user experience. So I just did the best effort to measure labels. Yeah, they will be there. If you want to have something more major, you can just suggest a pull request and edit the topic here. So we still have two weeks to process these pages and to improve them. But in principle, if you have an idea of doing something major in your plugin, we can just put it as an additional project, put some documentation and that's it. Okay, any other ideas, comments about this page? What's the most effective way to get a longer list of, I mean, we've got 13 issues, which is obviously not a lot, I mean. Well, actually it's quite a good number if we take big, big initiatives. So they'd be the best way to discuss them. Everyone is welcome to suggest project ideas in this Google doc. And basically you click here and you get a Google doc where you have published ideas and also ideas on the discussion. So what you can do, you can just put your ideas to this list. And that's it. So we will have this discussion, maybe in chat and eventually either publish it or not, but hopefully we will publish it. Okay. So definitely we need more tasks. I'm not sure whether we need more projects because for example, system read permission is a big project. I agree, tasks is more what I meant than projects. Yeah. People, a lot of stuff to change from because then there's more chance that somebody will see something that catches their eye on their ability level, let's say. Yeah. Also, yeah, there is tables to diffs immigration. So what we were discussing in my chat and the pull request today. So basically I have a crowd testing. Okay. But yeah, we'll get to that. So I just edited to the list so that we can discuss it. Okay. Any other feedback? Well, big thanks for putting this together. I mean, this is a big deal. Obviously it's all what we're doing. I mean, hopefully we'll get a lot of work. And I mean, if we're lucky, we'll get a couple of people that keep on working on it after the hack first as well. It's like, yeah. Fingers crossed. Is it, is anyone signed up here? Yeah. We have more than 20 registrations and speaking of people on this call, I guess it's only me who registered. And the most of these 20 people are not usual suspects. Oh, Vlad has also registered. So yeah, two people on this call. But yeah, I think that we can get a good number. So what we have as a kind of target for us is 50 contributors. Well, basically it's exactly a number of t-shirts we have secured for now. But if luckily we get beyond that, we will also see what we can do. Because yeah, 20 registrations, we never know how many contributions we will actually get. So we will keep pushing the event. And hopefully it will be a good opportunity to just get together in the community. Like we did it, for example, for Java 10 plus hackathon, where we had a lot of different conversations. It was the first time when some contributors met each other, even virtually, because in the sudden attention, there was no practice of regular video calls. Now with special interest group meetings, that's where we have probably a lot of meetings in the community. But yeah, in the sudden attention, it wasn't a case. So maybe now we can have even more community bonding. So if you have, yeah. Oh no, go ahead, please. Yeah, another thing we are planning to do, which is not reflected on this page, is explicitly highlighting that we invite people to do UX testing, including web UI and documentation. So basically participants will be able to just into some testing report issues, and it will account towards the hackathon contributions. So we won't be requesting only GitHub changes. So how do we kick something like this off with like a session, like a video call or a recording, how did this thing normally work? So yeah, we have some discussion again. Let me switch to the planning doc, because we have a tentative plan there. So we started assembling different events. Yeah, this page is getting a bit long, but yeah. So May 25th will be our opening. We have a confirmed session for one PM UTC. Right, so there you will basically just say hello, do some overview about how to contribute, how to record your contributions, et cetera. We hope to have a kind of opening course for all stories. So for example, for documentation, we have it confirmed with Mark for user interface. Yeah, it's actually a good question. So if somebody is interested to just do some introduction in 10 minutes or so, it would be appreciated. I mean, I'd be happy to give a short talk about where it's all going. It was just like five, 10 minutes, you know, like the kind of decision. People are, if you think people are interested in that, I mean, I'm not gonna give the introduction, you know, this is how the UI works. I think there'll be people that are much more qualified to do that than me. Well, it would be great. Yeah. And we could have some... And I'll also plug the SIG, obviously, in that, where is it going to? I mean, it'll be really nice if, you know, after this, you know, three, four, five people become, you know, regular members of the SIG or, you know, regular contributors, 10 or 20 would be even better. But, you know, if we got three, four regular people, that would be the third one. Yeah. Yeah, that's right. So, it's an opening session. Then at 3 p.m. on the 25th, then. Yeah. Let me block down my camera. I'll send the invites. So, it's just the development of the, basically yesterday and today. So, it's still a kind of target, but all the meetings will be scheduled and announced this week. So, I guess we also confirmed hands-on session with Ulia at 3 p.m. UTC, is it right? Okay. So, basically it will be handled in the forum of developer meetup. So, Ulia had a great block about creating fancy UI for reporter plugins. So, I think we could just reuse this content as a kind of overview session. And if somebody is interested, we can have more such sessions. So, the whole idea is basically to have a hardfest. So, if anybody wants to have a developer meetup or whatever, we can do that. Or just show and tell for a particular topic. So, for example, we plan a session about migrating plugin documentation to GitHub. Yes, again, but we will do this session. And I also asked team about system read permission. So, whether we could, okay. So, we just need to discuss the data, but in principle, we do this session. And so on. So, if you want to present a particular story, which is related to user experience, we can schedule this session during this week. And if you would like to propose something, just do that. All right. So, we can kind of make it into many conferences. We have the speakers that want to do that. Well, that's not an intent. I would rather prefer developer huddles. So, maybe a workshop like things or show and tell things with open discussion. Yeah. But doing a conference like thing, okay. We could... Well, like an unconference then, maybe. Okay. That's fine. Yeah. So, does this format work for you in principle? Yeah. Sounds right. Let's hope that we get a lot of people that want to contribute. Well, we will do our best to do that. But yeah, we already get a number of contributors and actually the timing is quite good. So, for example, for documentation, we have just announced JSOD, Google Seism of Dogs. So, there will be technical writers exploring Jenkins project and we have already got messages maybe from four of them, maybe more. And there we will also suggest this hack first as an opportunity to contribute. The same for Google Summer of Code. We also keep this option open. So, if students want to contribute, they're welcome to do that. And it's the main reason why we do it in the end of May before the coding starts. So, that firstly, we have mentors and students potentially contributing to this project. And it's a good opportunity for coming in the morning for them. Okay. And yep. Just if you want to invite someone, please do that. Anybody else that's worked on you with the club is on this? So, is it mainly you? So, well, it's a coordinated effort in the community team. So, what it means is basically me, Mark, Alisa and Tracy organizing that in terms of just doing all this back and think. So, I will be probably the main host for all the events. Mark is taking care of the documentation because he's a documentation officer. Say, Malisa is taking care about the events and spread the word part, including Jenkins, the WAI website. Then for UI UX, I would definitely appreciate some help with getting the thing running because it's a major topic. So, having more contributors would be great. But yeah, for me personally, I will be a full-time this week on the event. Well, maybe accept the necessary JSOC stuff, but yeah, you don't want any other events. And we already have a number of reviewers. For example, thanks team and probably we could get more people here. So, Felix, he might be able to participate. Then yeah, we would appreciate if there are more reviewers and more contributors since six. Yeah, I mean, hopefully we can just plan it. So Felix is more or less 100% available for this. I mean, I think it makes more sense to use his efforts during that week to sort of merge PRs and then that he works on, you know, other UI related stuff, but yeah. So, I have yet to go out of my name on the list there, but I'm also planning to allocate some time at that point to be available for some design feedback and that sort of stuff as well as contributions are made. Thank you. So. Yeah, that's great. It should be. Yeah. So we will keep growing these teams, et cetera. Yeah, when we were doing Java 10 plus hackathon, we had almost 30 contributors in total during this one week event. And I guess here we have a chance of having a lot more, I guess still less than 100, but still a decent number of contributors. And we really want to have it as a kind of community get together so that, for example, in a UX stick, you have a meeting right in the middle of hackathon on 27th, right? So for example, this meeting could be used for intermediate celebrations or something like that. What do you think? Just to bring people to this seed meeting. That's a good idea. Mm-hmm. Yeah, I agree, it's a good idea. Oh, okay. Now, the Dock SIG will actually meet, I believe it's the Friday before. And so we will use the Friday before as our sort of get it launched. The 22nd, we will be in the Dock SIG there, so. Okay, well, we could still do a special meeting during the hack first. Oh, we should, absolutely. I just, we'll also do preparatory work in the Dock SIG meeting, but absolutely we will do, we should do one during the week itself, yeah. Okay, okay, yeah, I'm just putting things so there anything else to be added or are there any specific topics you would have? You would like to have? Because I can reach out to contributors and see whether we could organize additional developer meetups. For example, I have a topic about developing from Tent and Jelly Groovy. To be honest, I would rather link the recording because we have some. But if we feel it's important to have this section, this session live, I will try to organize it so that I'll probably run it on my own. Yeah, so on the front end development, are there things there that related to the various initiatives that Felix is working on that should be shared for front end development, the styling, or is that, is that separate or leg? So, yeah, that's a good question. We can have some introductory meeting. We have a presentation by Uli. But this presentation by Uli doesn't really cover the topics we put in this plan. Is that right, Uli? Actually, my topics are a little bit specific to plug-in reporters and the special views in there. But I think Felix's part is more in the other area, how to style the individual elements of Jenkins. Okay. So how to style elements in Jenkins? For instance, yeah. Okay, I'll talk to Felix, but yeah, next week. But tell the connection item. So I agree that it would be useful. And maybe another topic which we could clarify. So if we really do themes, maybe we could have a how-to guide about creating Jenkins themes. But yeah, again, with all the disclaimers about theme compatibility. So what we did, we started the discussion about theme support policy. This is basically a text we discussed with Felix, and we have already got some positive feedback. So too long did it read, we just want to document the current state where we guarantee exactly no forced or backward compatibility for themes. And we keep it as is until the look and feel improvements are done. So this is the current proposal. And we will be rolling out a theme effort only if it's accepted by the hackathon. So my question to you, Joe, Jeremy, and to others, taking that this policy is published, are you fine with putting more themes? Because we know that it puts potentially compatibility at risk, but at the same time, the engine is already there. Could you rephrase the question, Oleg? I'm sorry. Okay, if this policy is accepted and published by the hackathon, are you fine with us facilitating theme development as potential topics for contributors? Yeah, I mean, I'm not immediately opposed to that because I think that this support policy outlines the parameters in a good way. So yeah, I mean, I'm fine with that. I think it was really important that we had this policy in place and this is a great guideline or series of guidelines. So yeah, I'm not opposed to that. Yeah, I mean, for me the same, obviously it'd be awesome if everybody just rode around the new themes that we're creating overall. But I mean, I think the power of Jenkins is people are free to do and style it the way they want. And yeah, so what Joe said, basically. Okay, so I'll tentatively add how to create a theme to the list, probably it's me, I'm not sure. By heart, try to email with the simple theme plugin. Yeah. So as a part of this proposal, I'm going to document usage of themes in admin guidelines because right now, if you go to Jenkins.io doc book, basically that is nothing about themes there and whatever. I will probably do a page at a page here and with all the policies, I will link it to simple theme plugin. So we will be able to highlight this engine, but vice versa, we will just define all the policies. So yeah, that's the plan. Any other comments, feedback? Because we already spent 30 minutes. So if you want to proceed to use other topics, I totally understand that. I think we might need to just for the meeting sake and for timing sake. Sorry, sorry, was someone about to say something there? I don't mean to cut you off. Oh, no, just I wanted to clarify, does it make sense to popularize this hack fest using different channels, retweeting, and maybe on LinkedIn and related question. If somebody who doesn't have experience with Jenkins at all, does it make sense to ask those people to join and contribute to different areas? Or it doesn't, so just wondering. Okay, so does it make sense to promote it? Definitely, yes. Any channel, we do some promotion on our own, but definitely more promotion wouldn't hurt. About newcomers, we explicitly say that we invite everybody regardless of their experience. For that, we firstly create new newcomer friendly stories. So there are some linked here, we will have more linked from other places than the same for documentation. Again, other newcomer friendly ones. We will also have a chat where everybody is welcome to come and ask. This chat has been already created by the way. So if you want to join. And in addition to that, we are, as I said in the beginning, we will have UX testing as suggested item. Again, it's basically, it's an area where we would benefit from newcomers, especially user experience testing for installation guidelines, for tutorials, for installation, for things like that. They, it's actually an advantage to be a newcomer. So it's definitely useful and it's much appreciated with some of the attributes. And related question, does it make sense to ask companies who are currently using Jenkins and entire CI, CD infrastructure from Jenkins, if they have any issues, for instance, documentation or related issues or we don't want to approach different customers? It definitely does make sense to do that because historically Jenkins is mostly a tool used by professionals. And it also means that the most of our contributions come from companies, well, as individual contributors or as company contributors, but from people who want, who use Jenkins and who want to improve that. So, yeah, if somebody wants to contribute, it's a good opportunity to start. We know that company contributions, yeah, there is a lot of obstacles, like let's say, contributor-reliance agreement, we don't have one, but still some employers have to approve contribution before joining. So for that, if they need help, they can reach out to us and also we have some things here which doesn't require you to write a code. So for example, sharing your story, just posting in social media or UI UX testing, you don't have to write a code and hence you don't have to get permission from your company to submit this code in public. Fortunately, there is not so many companies in the world who require you to approve tweets or whatever. But yeah, there are some. Thank you. Okay. So thanks for your questions. And yeah, I guess that's all from me. So thanks for your time. And yeah, looking forward to this hack test. Thank you, Ola. Thank you. I'll take the screen back for just a moment and I've got a quick share here. We'll see if I can get through this without coughing. I apologize if I need to go on mute. All right, so we usually take a look at a design deck of sorts and look at ongoing progress of some front end UI element styles. This week, it's gonna be a pretty quick and straightforward one. So linked here, we have some early iterations and I do mean early on table styles for Jenkins. So for a bit of context, because we have a couple of people on the call who weren't here last time, which is awesome. We link all of these decks and pretty much everything that we talk about on this document, which should be available on the UX sake page for future reference. So if you ever wanna go back and look at this stuff and this UI revamp initiative is outlined here if you wanna check that out. So for today, we're just gonna take a look at, as I mentioned, some early table styles, the intended outcome here being, you know what, let me do this since I'm not on the big monitor, being to update Jenkins tables to use a more modern aesthetic, which can then result in a more user-friendly experience. So not changing dramatically the functionality in keeping with what we've been doing in recent weeks here, updating styles, which does improve the experience, but not necessarily in a deep way, but we'll take a look in just a moment at some examples. So some ideas, and again, these really are quite early still are that aesthetic improvements may include things like taller rows, right? So more spacing, as we've seen in the sidebar and in our typography adjustments to padding, implementation of our newly-defined type styles and our newly-defined color palettes to make things more accessible. We also would like to try and implement some interactive states. As we've seen, we've established those in the sidebar work and things like that, possibly on entire rows and tables, which would create sort of a more consistent experience with some of the other elements that we're working on. Again, at this stage, these are just ideas. These are not being implemented currently, but when we get there, of course, we'll share that and we'll talk about it like we always do. So as I say here, we still need to do an audit, much like we did with button styles throughout Jenkins to see the wide variety of table treatments and table usages throughout the Jenkins interface, and that's gonna inform this work a lot. But for this very quick update for this quick deck, we're just gonna look at three screens. This is a screenshot of current table, right? The most visible table for a lot of people. And this next screen is if we were to apply some of the standard, excuse me, not standard, some of the styles that we are trying to standardize throughout Jenkins of adjusting spacing with some adjustments to our typography reflected here, adjustments to hyperlink styles. Notably, these are not with updates to our icons, which is something we're aiming to do in the coming ones as well, like we've talked about. So not perfect. If this were an interactive prototype, we would be able to see interactive states here reflected so that things are a lot more clearly selectable. When you interact with them, it's a lot clearer how you're doing that, what's being done as you interact with the table. Excuse me, I think we got a comment here. All right, sorry, it wasn't me. I just asked whether you were to go after green balls by default. So we need to look at all of this iconography and things like that, so I'm not sure. And click here. This is another mockup, just static for the moment, right? So applying the type we've established, the colors we've established, adjusting spacing, what could this plug-in table that we are all familiar with look like with some of these very basic adjustments and improving usability. So very early stages and much more detail to come in the coming SIG meetings on this, but I just wanted to share that. And does anyone have any thoughts or questions at this early stage on this topic? That is a beautiful thing that you have on screen right now. I like that the extra, the better text over the title, the name of the plug-in. Thanks very much. For now, it's just a picture, right? I have to stress that, so I appreciate that, but we're gonna see the limits of what we can actually implement in tables, and it really comes back to how they're being used, which I don't technically understand yet. So we'll see what we can do, but we'd definitely like to improve legibility, just general understandability of tables as they're used throughout the UI. Yeah, one thing to keep in mind is that plug-in manager UI is basically a separate project on the roadmap at the moment, and there is a number of contributors who change it a lot. Shout out to Daniel Beck, who basically wrote all the layout there. So I believe that changing of styles should be quite orthogonal, but if you want to change the content at the same time, then it might make sense to do some kind of denation. Yeah, absolutely, and that's a great point. This is definitely just like a static example, and of course, other initiatives are gonna include various elements that we touched throughout this project, but yeah, point taken, absolutely. What makes sense here for me is to look into several plug-ins of what kind of tables are currently used. So because these tables you are showing are not a typical table from a plug-in, I think these are some, yeah, they are using a table, but actually these things are not what I think about a table. So normally you have table or data, but this is some kind of detail information for the plug-ins, so it would make sense to look or have some other plug-ins or look into some other plug-ins as well. Yeah, I totally agree, and that's a great point. Thank you. That's something that we need to do as part of a table audit, right? Yeah, thank you. The tables are very difficult in terms of styling. We pass through the same on Jenkins IO. So for example, on Jenkins IO, we had many pages like, let's say roadmap, which follow the table layout. So thanks to Zbiniac and other contributors, we can apply some magic so that tables can collapse, et cetera. So basically, they still get flow layout, even though they're still tables in HTML. So maybe something like that could be applied to the, I'm not sure. Potentially, yeah, frankly, I'm not sure either, but we're definitely mindful of this and we'll see how far we can push the envelope to make them more usable in addition to styling and we'll let you know. Yeah. Thank you. For sure. I think our next item here, updating the SIG page. Oleg, did you add this one? Yeah, so basically, we already reviewed it during UIX Hackfest. So unless somebody objects, I would like to get this change merged. So there is already the approval from Jeremy, from team, from Mark. Basically, just some more details. Yeah, let's go ahead. Sounds good, yeah, go ahead. Awesome. Yeah, thank you. For sure. You wanna speak to number five and six there as well? Oh, yeah. So I don't always add topics, but when I do, I do a lot. There you go, okay. So yeah, if you don't mind, I'll cringe again. Sure. We pass it to team quick there in just a second. There I need to close, top side opened in a while. Okay, so we have a pull request which is related to replacing many tables in our layout to diffs. It's not that tables Joe was talking about. We also use tables to align components on the layout. And basically, it's considered as bad practice, especially in terms of accessibility and also because layout is very fixed. Also it makes it very difficult to modify that. And there was a lot long extended request from Josh Sorev about changing from tables to diffs. And just to provide some context, first time we discussed this topic was something like 2013 on 2014 in the developer manual list. And since that we have never touched that because it's considered to be extremely complex and potentially a break in. But yes, here we are. So thanks to Phoenix, thanks to team and other contributors and thanks to Joseph. We actually have a pull request which does a first shot of changing bed. Yeah, it's a massive change across the Jenkins web interface. So basically replacing a lot of tables which I used to render layouts. This change is likely to be a break in one. That's why we postponed it until the LCS cutoff. But the new LCS baseline was selected. So technically we can merge the end weekly. And there is some going discussion about how we could merge it. And basically there are two ways we discussed over past day or so. So one way is to just lend it before the hack fest. And well, likely there will be regressions. So we will invite contributors to work on that to fix these regressions. It will be a bit of a boilerplate but it will be more convenient for contributors. Another way is to actually do crowd testing during the hack fest. So have several contributors and write more for this project. We can provide to them, we can provide ways to test that but it would be a more conservative approach. So what I wanted to discuss, he is basically to get a feedback from the seek to see how we would like to render that. And the team is still on the call I guess. Yes. So team, it would be great to know your opinion because you've been driving it a lot at this time. Oh, it's muted. Yeah, yeah, both work. Not sure of the quality of testing that we would get in depth during the hack fest. If we merge it at the beginning of the hack fest, then the version of call that people will be working off would have this in it, but it wouldn't be released. Which could catch some issues. It's more likely to catch issues if people are working off of that. We could have a bug bash and see and ask people to test it. But we can do bug bash anyway. So the challenge here that we will need to provide guidelines how to test that. For example, we did it for Java 11 before. We created a development branch. We set up incrementals delivery for them. We set up Docker delivery for that. But basically during the Java 11 hack fest, we had a branch in the Jengar score repository where we were integrating changes. And thanks to our CICD environment, we were getting versions after each merge. So we could do something like that. We will still need to document that, but in principle, it's possible. But yeah, you're right that it might be a bit more complicated. If we just merge the thing, of course, it will be easier. But yeah, I'm not sure what would be the consequences for users. To test it with more plugins, I guess. The plugins that I have installed are all working fine. There's always going to be insane plugins that are likely gonna have issues. So yeah, for example, in Java 11 hackathon, yeah, I tried to find links, but we were coordinating it through Google Doc. So we had a Google Doc where everybody was putting what exactly they tested, which plugins, et cetera. And actually we got a good number of contributions through that. Same for example, for JEP 200, when we were doing that, we again, we were coordinating it through Google Doc where every contributor was putting the changes. Yeah, that's a wrong blog post. But if you have multiple contributors who are interested to work on this topic, we definitely can create a framework for that, for comfortable testing and for collaboration. And hopefully we'll get some contributions and test coverage out of that. Yeah, the thing I'm not most worried about but quite worried about is if we do have big changes to the UI or semi-changes to the UI during this hackfest is just having to rework the PR to adapt to it, given that it already touches a large part of the UI. So it's a fair point. So your preference is basically option one. Yeah, option one or? One. I mean two works for me as well, a preference for one, just because I don't want to have to rework, retest and conflicts again and again and again. Just because of how wide-ranging it is, I feel like Java 11 is different. Is that a lot of the changes could be mainlines in Java 10? The Jaxby stuff may be more difficult, but... Yeah, so just to clarify in the case of Java 10, we had a hackfest, but then we had a feature branch maybe for something like three or four months while we were gradually moving our hacks to the main branch. So here, definitely we would prefer a faster process because if we assume that we want to merge it in this LCS cycle so that it becomes available to LCS users since September, then we just have two or three months to stabilize the ecosystem. But still, we probably don't want to break it completely for weekly users. So if we have confidence that the majority of plugins are likely to work, we could merge it. If you don't have confidence by the hackfest, we would rather go towards option two so that we try to do crowd testing. Yeah, as far as I'm aware, it's matrix auth and ECM API. Plugins need merge and release. Yes, almost like little strategy will break. I don't think it will, but I haven't actually tested it because I don't think it's part of the default. Recommended plugins. No, we recommend matrix authorization right now. Yeah. Well, so... I'll give that one a check, but I don't think it does just based on its UI. It's different. Yeah, so basically all strategy plugin renders six pages on its own. But yeah, so we have something like five minutes left, but yeah, for the seek, if you're interested to discuss that, I think this call request is the best location. And I think we need to decide within one week or so how we proceed. Yes. And yeah, more testing by anyone would be very useful to help us with that as well. I think we've had a few people test it, but more as welcome. I did a mailing list post on it as well. And the documentation updates, PR as well. Yeah. So whatever way we choose, I think we want to add that to the hackathon. So yeah, these, the question is rather, what exactly we will be doing there? There's more work on top of it to be done as well. There was things that we aren't happy with, but they're just riskier changes and more work. That we didn't want to leave in the scope of this. Okay, so let's see. But yeah, let's keep talking about that then. Yeah, once it's merged, I think it will be a great improvement. So I tried it on, yeah, for narrow screens, well, something less than 1,000 pixels. It's a narrow screen in Jenkins. Yeah, this layout already gives a lot of advantages. I'm not even talking about launching Jenkins on mobile phone. The principle would be an interesting project. Well, this makes it render a million times better on mobile, just with no effort really. It just works on mobile, a lot of things. Yeah, right. And the previous changes by Felix and the header also improved the situation. So, yeah, let's see. Okay, anything else on that topic? I've got four minutes left, so. That last one may be pretty quick. So, Oleg, I know you had added, as a discussion point, UXSIG logo, and you shared some drafts of some concepts there. I could speak to it real quickly just because we talked about it earlier. It's something that I'm gonna, I'm gonna try and create something for us as well, maybe work on new iteration of your concepts as well in the coming weeks. So it may or may not be ready by the next SIG meeting, but this is something we can upload onto the SIG page and makes a better impression when we share on social media or in other places and other venues about the SIG. So that might be all there is to say about that one, but do you have anything else, Oleg? I know we're coming up on time here. Yeah, I think just quick one. So, yeah, if you want to take a look at better examples, you can go there. I deliberately not showing them because most likely Joe will come up with something much better because he has spent just several minutes. And yeah, so right now, we basically have a standard Jenkins logo. I believe somebody at some point could be pasted this logo from Jenkins web interface to Jenkins IO website. So the resolution of this logo is quite small. So even here, you can see the pixels. And when you post any link to your SIG in social media, basically you get huge logo as open graph and it looks, well, not very good. The default repeated is to be the Jenkins logo. No, it actually puts this logo. I know, but the Jenkins logo might be a bit of a default. Yeah, it might be. I think it's probably. So we applied some magic around that. So here, open graph, it just puts user give. So if you remove that, it will put Jenkins logo, which is definitely a better option. But yeah, if we have something else, it would be nice. That open graph is what Twitter will pick up. Twitter, Facebook, Slack, if you post it in Slack. So for example, I repost all the Jenkins, but posting Slack and when you see images, so they come from open graph. Okay. And yeah, this is a standard method. It's available on almost all Jenkins pages. Anyway, it'd be awesome to have a nice little logo. I mean, there's nothing fancy, but anything's better than those two little men or people. Yeah, so one thing about logos and other design, so there will be some of design or something like that. So basically it's like summer of code, but for designers, it's organized by whatever company. So if you want to post some project ideas, we could discuss that maybe at the next meeting. Okay. Yeah, most likely we'll be a bit late with that. But in principle, if you want to participate in such programs for design, we could do that. Because yeah, one more week. Sorry. No, I was about to say we're at time for this call. Sorry, go ahead Oleg. Yeah, I also have nothing else to say. Yeah, thanks a lot for your time. And sorry that I spent almost all your time today. No, thanks for bringing stuff to the table. It's appreciated. And thank you everyone for your time and great session. Yeah, big thanks for organizing the hack fest. Thank you. That's all right. Bye. Thanks. Have a good one everyone. Thank you. Bye.