 Welcome everyone. This is Jenkins user experience special interest group is the 20th of July 2022. Thanks very much for being here reminder that we abide by the Jenkins code of conduct conduct in our meetings topics proposed for the agenda today security reviews for pull requests and I believe this is you then UX improvements and Daniel added a new one, a subtopic there UX paradigms. I had required Java 11 and fully support Java 17. And this one on stalled UX pull requests had been added. I'm not sure if there's anything to say other than that I haven't done that action. We had an accessibility assessment that I've made no progress on as well. Are there other topics that you would like to put on the agenda before we start going through the agenda. Okay, vatic, then let's take on security reviews for UX pull requests. This was not my topic. It was added by team last time I think, because we wanted to review that after one more for this kind of thing. What is the status and like, are we blocking too many pull requests before to put reason. Are we able to allocate the correct resources. So I will say from my side, I would like more to get feedback from the community there like, are we blocking too much the thing. Are we sufficiently active or not. Yeah, I mean, it's at least one that's been waiting for a month and hasn't been looked at from security team. The symbol change or which do you mean. Yeah. Yep, so I definitely plan to do that. Just haven't gotten around to it yet. Yes. Another one. See when the label is added. Yeah, nearly two weeks for the colored node labels. It's been waiting. Right, but there's an ongoing discussion exactly how that one would work. And if the PR requires substantial rework. I'm not sure it makes a lot of sense to review it now for how safe it is. Like for example the last comments I remember is whether there's a selection of colors or whether it's completely free form. And if there's a selection of colors. There's probably not going to be a text field where users can enter whatever right. So I think I think I've raised on the mailing list about having some sort of label for some sort of review review done and not in needs addressing like this one here said potential CSS injection issue. But there's no way to tell whether this is pending a security review or not. I mean, from my point of view, generally it's okay but some of them seem to wasted a bit longer than they should have. Generally going. Okay. So Tim, I'm not sure I was trying to capture the notes on the label idea that you had and I missed that could you do that one say that one again. So if there's an issue with the progress and it needs a correction. There's no basically so the tippy one that is some work that needs to be done on it to add some more tests or fix some tests. It's not waiting for the security team right now but it says needs security review. And basically there's only a needs review and review complete and review approved label there's no Okay, all right so we need, need a need a label that says security fix pending or security fix needed. Possibly. Okay. So we want to continue this process so not sure how it's working for the security team with a. They have and how long they will have the people to keep reviewing all these PRs and whether it's been official. I will say it's until we are no longer finding vulnerabilities in request for such things. Because it was really recently we discovered a lot of things related to the new UI stuff we are working on in the request. We got close to no new vulnerability added so it's really to be a more stable in terms of the situation. The cost to correct something during a poor request compared to once it's already merged is so huge that we can just let the things moving on there. Now if we are reducing the number of things that we are finding. It's totally fine to reduce completely this kind of policy for the review. The goal is really to keep us doing an efficient amount of time, working on the security aspect for color to not just waste time because we were not able to audit the field before the project. Yes, so so but I think that was an important point from my mind is, is you're doing it like it's cheaper for the security team to find the issues before the PR is merged so reviews are a really good thing for you that's a positive for your team, not not anything you consider as oh I just a cost it's really a benefit you're avoiding avoiding later work by doing earlier work. All they will say there will be no new security fixes so we have nothing to review and nothing to correct, but as it's not really the case. Yeah. All right, so, so then is the the message I think I'm hearing is, we're happy to continue the process. Should we keep this as a regular item on the agenda just to be sure so that we can look at these things saying hey, if something's been a long while, I could certainly prepare. I didn't prepare for today I could prepare lists of things that have been there for a while. If that if that helps. Yes, I think we need to keep the other point every time to discuss that to check the temperature what is the situation and so on, because if at some point we are not able to continue that effort for security team. I don't want us to block everything from the communities. Great. All right, so, Tim, does that work for you all just included on the agenda regularly and we'll, we'll raise it and check in another month to see how we're doing. Yeah. All right. So quick remark regarding the reviews. So I checked and, of course, acknowledging that it's typically the simpler poll request that gets reviewed quicker. We have three that neither review and 30 that had a review. Oh, okay, good. So three need review 30 have been reviewed since we started this and our approved is good. All right. Thanks. Okay. Anything else on security reviews. So on this topic then we've had a general placeholder UX improvements for Jan and Tim. Daniel's put this one on as a subtopic Daniel should we take that one first UX paradigms. And then Tim if there are if there are things you want to discuss in terms of other UX things we would we would then give it to you is that okay with you Tim. Yeah. Okay. This is basically a repeat what I wrote in one of the one of recent poll request reviews. Let me pull it up. So what I noticed is that it seems we kind of introduce completely new UI elements in otherwise unrelated changes without considering how that impacts the larger plug in ecosystem, for example. So in that particular case, we have the new job configuration form that is integrated in Jenkins to three is 60. That is the only page in Jenkins where the page title is on the site panel rather than the main panel. And there's a new poll request that changes some stuff around in the plugin manager, where that was also done. So my question was, is this a new thing and Jan's response to that was. Yes, long term, all pages should move the page title to the site panel. And for some quite that. Don't believe. Hold on. I'm not suggesting a move to titles above side panels just yet as there's still lots of thinking planning designing ahead to make the move make sense. Although in the first response was end goal I think there would have to be the site header above the site panel if the page has one. Just right now a lot of pages haven't been looked at. Especially that first response for me means the expectation is that every view in every plugin would need updating to move the title. And while that's certainly something we can discuss, I don't think having it be part of other changes in this case, moving the scrolls by tabs to the site panel the first PR, or the tabs of the plugin manager into the site panel was appropriate for that, especially since it essentially means we either have more inconsistency across Jenkins, or need to adapt hundreds of plugins probably, especially in ways that are potentially not easily done with how we use side panels, because we reuse side panels for multiple pages. And that probably isn't quite possible with this I haven't looked at the implementation specifically. And the other is the poor request to plug in manager introduced a separator in the site panel, which tends it's nice to look at. But then the question is, it doesn't show up for example in context menus that because there is no support for separators in context menus so it's, it feels half baked, and I'd rather not have a change that doesn't work with the rest of Jenkins. And while these changes individually are something we can discuss, having them sneak in in another poll request that changes something mostly unrelated to me should not be done. So, I'm struggling to under so the, the plugin manager moving the title into the side panel seems like that was, that was quite intentional, not a not a total shift of everything else. Daniel, can you help me understand better or maybe I should open up the side panel, the plugin manager pull request to see the picture of the UI. So it seems like that could be isolated. And that one panel switches its title location others keep it the same as they are, or is that your concern that they we should have them all on side panel or all at the top. So the problem is, it's an, and it went unmentioned as a change in a pull request that changed something else about the plugin manager largely something else. And when I asked, well, is this the new thing because it was the second time I saw it. The initial response was the long term everything should be changed. And to me, a one of change in an otherwise unrelated core pull request is not where we should set project wide standards for all of you was that have a lot of downstream work attached to them. And so my pro proposal in the pull request was well, have something checked like so that these changes that affect many developers in the ecosystem can be reviewed and discussed in advance, rather than say, you know, a few weeks down the road. Hey, this exists now so time to use it, which is kind of how I feel about the app bar. So, Tim, any insights from you there any guidance you want to offer I think we have differing opinions and I think not sure how productive it is right here as well to give reasoning. Okay. There's one where we bring the discussion and the differences of opinions into the pull request. I think it's being discussed there currently. Okay. Yeah, so you're on your reply to Daniel's concerns. Two days ago. Link be shared that pull request. It's in the chat. Yes. Here I'll just pop it open and make it big enough to read. Okay. Right so this is the before case, and this is the after case. Right so Daniel I think the topic for you was the word plug in manager at the top sort of left there be moves into the sidebar. So that the search is the top most focus in plug in manager. Do we use that framework anywhere else on any other sidebar and Jenkins don't believe. Yeah, so I mentioned one other pull request where that was done it's in the latest weekly release of Jenkins in the job configuration form. The job configure. Is it on weekly CI already mark. It may be yeah let's look. It will be yeah. If, yeah we're at 360 so if I do. If I do configuration. Yeah so let's just open this job and figure it. Good. I love. Okay so here the word configuration is in the side panel. Right and right so this was the first one major changes to be doing piecemeal. Well it's the only way to do that sort of thing. Right. I mean, not, not quite as piecemeal, we can do something like more for example. We should be like planned with a plan and schedule then no because otherwise won't there be some that use the sidebar for the title page title some that don't. Which which is kind of my point, really, and especially since this is something that if it's something that should be done Jenkins wide. It needs. First of all it needs feasibility review by others who may think of some issues that perhaps hasn't considered by just changing one individual view, and then it should be done. You know just planned and, you know, core at a time, more or less, because that may well reveal issues in implementation. That are going to be a problem. And if we already changed off the application and only notice it then that would be a problem. Do we have tools underway for translations right. Where titles may appear in, in different languages. Yes, yes. Tell me what your question is that title in German would wrap. It's a very limited space for what could potentially in different languages be. I object, I object, you change the sea to a K and it's German. For a previous project that used to blow up our, like, I'm just saying like it is a very limited amount of space, and I'd be curious to see how it scales for. Not all of our page shadows will be as concise as configuration. Plugin manager already was shortened to plugins, right. Yeah, so it hasn't been a request now to change all of them it's to kind of experiment with a couple of the pages where this makes sense where they're quite self contained and specifically not plugins. But I don't like, I mean, Jan's not here so I don't really want, I don't know the exact reasoning around things. I mean, sorry, this may be a silly question but has the open source community kind of a B test and the stuff among yourselves like do you ever share things with like a limited group of people like soliciting feedback or do you put it out there and tell someone if there's any complaints and it's something that's evaluated like is there a formal. So, usually the review is done in the pull request before we merge. So that's where the comparisons are done. There's not any a B testing of users after merge. So, I'm sorry I'm stuck trying to catch up here so Tim I think your, your note was this this configuration form is relatively specific. It's configuring a the job. And, and with that specific configuration form. It's an intentional exploration, could we do more of this move the title of the side panel but it's not a requirement that we must. Part of this piece of work is looking at improving the side panels for pages reducing what's on there and simplifying it so not so not just dumping a side panel with 20 actions on it, which is what like you often gets. It's a good dashboard on maybe maybe see I don't change style but probably probably more likes someone who's got a million plugins as well actually see I don't Jenkins that I was a great one because at least for me the side the side panel is enormous. Yeah, and that's not a very big one, you'll see. Yeah, I mean, yeah, that one's pretty crazy but I'm more thinking like the dashboard just how some crazy actions get there and everyone puts a link there some more about looking at places that we can prove this. And so it's like targeted a couple of areas first so there's like the navigation here and plug in manager says some there's been some work done to do things like get rid of those back to dashboard links all over the place and some guidance been put out that you can see in there so there's a draft forecast on the design like design system or whatever it's called that give a guidance that those so you shouldn't include back to dashboard links as people should be navigating via the breadcrumbs. And I think there's a similar similar back buttons basically and there's more buttons sometimes there's two buttons for navigation, and it's about when the different layouts be used. And we're trying to do it all at once. And we definitely don't have the resources to do it all at once or do the AB testing and whatnot. Yeah, and that that's my, I think I'm aligned with Tim's concern there that I like the incremental approach. Daniel do you have any, any suggestions of, okay this one was, was a change that you're worried will affect could affect many plugins in many ways if we do it more broadly. Right is that I think that was your concern is that the side panels used in many different ways, not just this context. So, this particular change so this is the one that's already live, and I had no problem with that because this side panel works differently from all others for a reason right it's the navigation inside the current page whereas the side panels go to different pages. So this is already different. And previously the side panel in the config form was just empty. So, for this page, it is different. So, making it more different wasn't really much of a problem. I noticed it only when it was done for the plugin manager, which has the classic navigation between different pages, where it was also added. And to me, the plugin manager side panels is useless at the moment though so it's got the two buttons that it's not supposed to have it's got a back to dashboard button and a managed Jenkins button. But otherwise it is a side panel like any other in Jenkins, where it navigates to pages. And in that it is different from the job configuration where that's not the case and so I spoke up only in the plugin manager pull request because I noticed it. And wouldn't make any difference if we did a PR to remove it and then do a separate PR to read it. Because like the side panel right here is a absolutely useless one that's doing nothing. I don't object to the movement of the of the table tabs into the side panel that's not what this is about that's a fine change and I say so in my review. The title in the site panel is the problem because it is a side panel like any other. And so that means we introduce a new way to have page titles in Jenkins. It's the same with the unrelated pull request, and the same with the separator. For example the separator I would expect there to be support to have separators show up in context menus, and there isn't it's just an HR. And so the next perspective a title and a sidebar is so problematic. I mean this feels like a major change that. So Christina can can you help me with that one I, I was feeling like this change for instance is a net net significant net improvement for me this this one. cases you're going to find it's fine. But I think it's going to be impossible for to predict how that would scale across different scenarios. And to only have page titles on the sidebar in some cases and all, like, from a UX perspective that's as a fun simple example. Sorry, you were saying. No, go ahead. My example is basically the main page of any job that has in the title, something like freestyle project, hello world, or something. So, could you could you access that pipeline hello world, right, and especially as soon as you use multi branch pipelines or organization folders like we have on CI Jenkins IO. Everything becomes pretty long pretty quickly. And then you try to cram it into the site panel. Now, would job pages be exempt from having their title in the site panel to prevent that problem. It's an approach but it seems like this needs more planning than whatever is the next page that we're working on and doing it there and may very well be that they belong in the side panel. It just seems like it needs more investigation. But that's just my two cents. And say in context of this page with the first link that appears on the page be recent changes. Like the pull request was kind of the ideal thing right you want to feature search search is prominent at the top it works in that context. That's not going to be the case for every plugin right. Where the first thing at the top of the page like in this case recent changes. You know, you weren't referring to cyber suddenly everything below the title for every, every plugin that receives this treatment. That now becomes, you know, the first thing that they, they see on the page. Is that desired. I'm, I'm afraid. I'm not saying that this isn't the right solution. I just think there's going to be weird little like that would seem strange to me to arrive on a page and just say a plain text that gets my first without it, without any context. Because if I saw a title over the sidebar I would equate it to the sidebar links versus the page content I'm on. I'm, I'm, I'm pretty sure I'm not following so Christina sorry, let me get us to a page where I think can highlight what you're what I think you're trying to say and then you can tell me no mark you've misunderstood so. So here, the configure page has the word configuration on it and. So in the right panel, general is right there it has its own subheader things have context they make sense because it that content in particular sits okay with the title removed with all pages. Or we have somewhere it goes right into kind of a list of links or a list of, I don't know what the possible scenarios would be, would it still read right in that context or would it seem really awkward and disjointed. I don't think it's something we're going to solve on this call. I'm just saying like, I would recommend looking up some edge cases, mocking it up and seeing if it still sits as well with some obscenely long titles. So, so I think I think. It hasn't been proposed to move it on any other page so right. But again, again yarns not here so rather. Right, I think. Take a look at the recording and see if he still wants to try and move that there or do whatever. Yeah, so the so Daniel I think your point was this one, the job name on on the page for a job is potentially very, very long. I know I've got several like that. So, so that part I think I understood it's this this text wouldn't in the general case fit on the sidebar but young certainly hasn't proposed to do that it's just, you know I have a pull request for it. Another, another question is, I assume the ad description sits on if there were a description added it would sit under the title correct. Yes, it would description goes here with description persist at the top of the right panel or would it also moved to the sidebar. So it when I say that it will appear right over here. So if I had a paragraph of like a short paragraph of copy there, because I don't think there's a character limit right. There is no, there is not. So, but I mean, not knowing how or how your customers may use it. There may be situations where they may have quite a bit of quite verbose descriptions does that now move the links down the page like not saying it's not a potential solution but that there's. It's, it's easy to look at like one ideal page where it works well, but there may be pages like depending on how someone is using it. That may not work because then, if you may pipeline hello world over to the left nav. What about your ad description button on the right. Does that just continue to float there. And then this link on your right panel adds text to the left nav. I think it kind of created this jointed experience, but not going to solve it today. Right. And just to be clear, I, I do not object to doing this. Right. I just think I expect there to be problems like we discussed just now. But it needs more planning in a way right. So, first of all, it needs to show that pages like this one would handle it if the idea is to roll it out widely on most all views. And it also defines standards like for example in this case, if the pipeline hello world moves to the left, then the first thing shown on the page needs to have an extra title added in this case you would have a title that just says description for example. Right so basically you ask guidelines how this should be implemented so that it looks reasonable and works reasonably well. And so seeing changes like this in PRs that do something different for me is a huge problem. That's it. It may be what you move towards it just needs to have issues on your note. I just, I just wanted to bring this topic up in this group. So everyone on the sake is aware that there is a discussion going on. And I think as far as I'm concerned we can move on. Great. And I think I've understood so there are there are specific cases and Daniel no objections to this one that's already merged for instance it's it's a good. This is a good positive change, a good improvement and Christina your UX observation was hey this actually matches well with a person a user's experience, because of this word general here associating there that makes sense. In some cases yeah it will flow like that and it will sit fine and then that page you have the option to add a description. Right. Okay, good. And a description would always sit with a title. Maybe not. But it's a question that it would need to be answered. Okay, great. Thanks. Any objections if we continue onward then. Okay, good. All right. So, Tim. Anything else that you wanted to bring in terms of of UX improvement topics or things where are there other topics that are on the list. I was going to show a developer improvement thing for the chicken CI org. Something I've been working on. It's called. GitHub comment tops. So missing the link. Well, or do you want to just share your screen. Okay. You tell me what you prefer. I am happy to share my screen, not the least bit shy. Yeah, I can share my screen. Let me find Chrome. So you should be able to see my GitHub window with GitHub comment tops. Cool. So, I mean, something that's been a bit of a pain for quite a while is that. There's issues for people who don't have access to the repo directly that they can't do things like they can't request reviews from people if they're not if they don't have right access to the repo or triage which is very uncommon. So especially for individual contributors and often people don't get the notifications or they dismiss it and they don't come back to it. But other issues like having to rely on triages to come along and label issues and pull requests. So gap issue templates mitigate that a bit by allowing you to set up sets and labels through templates. But then basically, we rely on contributors triaging rather than person issuing it may be able to triage it at the time to save some effort. So in general, we have this like free for all anyone can do anything sort of thing, basically anything. And I was just trying to build something that brings what we want back or brings it some of it to GitHub to make it easier to work with and improve the developer experience. So I built a tool that handles a few commands and I'll just show you some of the commands and then maybe a bit of how it's built and I'll show you like what you can do with it and how quick how it works and stuff. So I guess these are the commands that I built close label remove label reopen reviewer and transfer that's a common issue is not common. We don't doesn't happen too much but we do have quite a lot of repos on GitHub now. We don't need transferring too much but you need to have, I think, at least right, if not admin access on both sides to transfer an issue. So it might be right on both sides but basically you need to be the owner of both repos to move it to a different place. So it's not ideal and there's no way to change that in the GitHub Commission settings. So you're basically there's some calling tops where you can go along and move things around. So if I go to my org just random repo have here. So example here. So if I want to remove label bug dependencies. Good first issue. And then the bots so the bots just edit just original and I just want to say slash label. Good first issue. And maybe enhancements. No with a typo. Sorry. Not do it with a typo. Sorry, what about do you say title typo typo so make a make a tight and intentional typing error. Yeah, sure. This is not. Exactly. Cool. Nice. Okay. So what you've done is effectively granted them the ability to add and remove labels, but or to add to label and unlabel but not to define a new label. Yeah, so if I go. Yeah, exactly. So there was the annoying thing with the GitHub action that I tried first that I popped in some of that Jerry get hub stuff is that the GitHub action would just create labels whenever people did that and was like huge fan of that. So and of course to do such clothes not planned as well. So you can do the other close option. And then so that's an issue. So I could transfer it to a different repo. Sure. Oops, but probably won't work. And I don't think I had a nice feedback on that one. Let's try that one. This one's a bit slow the API is not very good for it like it's everything just gets a bit funny I think it's a bit weird on the GitHub side how they've implemented it. It takes a lot of time while it's transferring and sometimes it will show up immediately and sometimes it doesn't just how to get our API or just how this whole feature works. Sometimes it takes a few minutes to even show up that it's moved. But see it has moved up in the new place now. So that's that and then the other thing is pull requests. So Jesse asked, like, what happens if you try and close a pull request is someone with no commissions. Like if you're going to spam stuff it doesn't do anything. So you can't you can't close a pull request. Currently just ignores you well there's an error. But but you can do things that you would like to do is do like you can label this as a bug and a dependencies. Oh, it's already got dependencies. So you can remove label dependencies and label is probably quicker than you can click through to get your eyes well. So yeah, I mean, let's see what else is there for just want to ask those clothes label remove they will reopen review a transfer so that's all of them. It's based off of a, it's using the opto kits. Library. So it's got a GitHub app. It's just a GitHub app. It's installed on. I think I've installed it on my personal account and my, and my org has a webhook secret which is mandatory with the library so you have to verify requests. So you don't have to worry about people trying to send your requests because you've got a secret that is the HMAC of the body. So the secrets, they say they add a header to the request they send you with an HMAC of the body, which you need to compare with with the secret so it's a shared secret that you enter here and store locally. And then a private key which is used for interaction back with GitHub. It's multi-tenanted. So it uses the events. So it's not so if I go here you get the recent deliveries and something I didn't know before doing that as that things like the installation ID is passed here so you don't need to try. You don't need to say that this is a Jenkins CI app or or anything. So the event tells you which org it's actually working with and which installation ID you need to use to get to get a token. So you can use things like this or if you're looking for the GraphQL API this and you can get all the information you are completely statelessly. So you could install this on as many orgs as you wanted and you don't need any configurations completely zero configuration. So the only figure back here. There's only three values you need to provide app ID private key and a webhook secret. And you can pretty easily just so it's just running on my laptop at the moment. It's a bunch of bunch of rejects is currently. I plan to do a little bit of refactoring on to extract it extract it and test a bit more. But it means I can post one comment with like five commands and take care of the entire thing at reviewers at labels remove the wrong label. Not currently but sure. Okay. Okay. So what's your one one comment at a time. So our one command per comment is the current implementation. Yes, it returns currently since it finds them. Since it finds a match it backs up. So is this. So the plan is to apply this to select repos in Jenkins CI or how would that work. I was thinking to apply it to all of Jenkins CI and possibly Jenkins Infra. So that you don't so Jenkins CI it's most so it's to allow both so so any poor request anyone can request reviewers without needing to have access. It's doesn't so the only thing doesn't work is teams if they don't have right at if they don't have read access. It doesn't work unfortunately. So if I go to this poor request and if I go slash reviewer at Tim J dash org slash core developers that will work. But if I go slash reviewer at Tim J dash org slash your key vault plugin developers that will silently fail just get a hub doesn't error if they don't have access you just can't add them. So it returns to 200 happily that could possibly check and see whether it got added or something, but that one certainly fails. But yes, so this allows you to request the team that owns the repo to review it when you don't have access and if you're just adding it to select repos you don't really get the benefit. And it doesn't have to be Jenkins Infra. It's just a suggestion for Jenkins Infra repos are revealed a bit closer but yet but there are still plenty of repos which are abandoned and PRs people come chasing PRs for five months later because no one was watching the repo. Yeah, so the thing with the reviewers definitely makes sense that get up doesn't allow it is really weird. I'm less sure about you know labels, for example, because if people just go not supplying every label to a thing or you know just well meaning, but doing it wrong, which I've seen on some of my repos, then yeah, but yeah, still looks looks pretty cool. Let's see, for me, I think the risk of mislabeling is less than the value much less than the value I get from having them at least propose a label. As a maintainer I was going to have to visit the labels anyway, if they since as a submitter they couldn't have assigned them. Isn't it. It seems like it's no worse for me to have them propose the wrong label than what I would have received previously which was no labels. First you only looked at every pull request once now you need to look at every pull request every day because it can be done whenever I see I see so your point is it would allow adjustments of labels, if they were if they were feeling malicious, or or feeling like they were adding value and not I mean they can be meaning to be helpful but don't understand how you use labels and it's suddenly a problem. So, but still overall this looks really cool. And that with the reviewer request, definitely a huge improvement. Not sure whether I would want the entire feature set on every repo by default. Tim, could you take us back to the list of sorry, the list of commands again. So it was, it was close, which is it checks if they have permission then it will close it no it's. I know it's so they can close issues, but they can't close pull requests. Okay, all right, it's only for issues and I see okay that okay. And label the labeling operation Daniels talk to reopen is the inverse of clothes. Okay. And slash reviewer, I would expect universal agreement slash reviewer is a great choice. And then transfer. You said transfers relatively low use right now but as more and more repositories choose GitHub issues, this may become more and more of a thing and I think I have seen it in Jenkins info. Much more frequently where a help desk issue may need to be transferred to another repository as the better location for it. Yeah, okay. So what's the what's the next step here Tim is it to Daniel do you want more time to review do you want more time to consider how Tim how would you like to get those comments. How would you like to see those. I would suggest that I am not the one judge to decide whether this should be installed or not. So please leave me out of this. I'm just one among hundreds. Okay, good. I'm fine with that as well then. So it seems like the Jenkins info. It's a good topic to discuss with Damian and the info team, because I could see this being helpful and in for even if it weren't deployed in Jenkins CI. Yeah, I've created credit help discuss you this morning. There's been a bit of discussion on it. Herbs asked a few questions in Jesse and Alex, but yeah. Great. Yeah, and Daniel in the chat notes, probably a good topic for the developer list. Maybe if it's okay what I'll do is I could, or Tim I can give you the link to the video of this so that we can point people to the demo as a starter and say hey look here. Here's this idea of a thing we think would really help if we had it in in the Jenkins CI GitHub org. Okay, great. All right so dev listed is thanks Tim. Anything else you wanted to show there. No, not right now I've mostly been working on this since some of the jerk have stuff. Great. All right, thank you. Then next topic that I had was. Oh, it's the Java 11 Java 17 thing. I'm not sure we particularly need anything there other than let me share my screen just so that we've got it. Okay, so you should see oh and Daniel you had added CSP compatibility that one Daniel with your permission I'd like to move that one up. And take that one now rather than spending time on Java 11 Java 17 because I think CSP compatibility is more interesting to this group. Okay sure as long as the other two topics that you also moved on should not be discussed now. I think this one I have nothing and the other those are just two saying Mark hasn't done what he said he'd do so. All right, so I recently restarted my work on making, at least Jenkins core, compatible with content security policy for the classic UI. We still have a lot of inline JavaScript that we need to take care of, but it's going fairly well, as you can see by the 23 pull requests I opened over the weekend. My suggestion and why I'm mentioning it in this group is, I would propose that at least for Jenkins core, but perhaps plug in maintainers can also adapt that a kind of a standard if you will that new JavaScript code or substantially change JavaScript code should be compatible with CSP. So basically saying, why we're cleaning it up. Let's not make a mess over there at the same time. When you say CSP compatible help those of us like me who are not not skilled in that. Does that mean it needs to not be in line is there more to it than that. So it really depends on the rule set that you're applying, but it needs to be what I mean when I say it is don't be in line. I think it makes jelly variables with obviously inline JS have modern style form validation URLs because those are just inline JS as well, and do not use eval in your code I think is are the big ones. And for a review, I think the UX think of themselves aren't doing that but it does come up in other PR sometimes. Okay, so Tim your point is this is this is already relatively common behavior for for the large changes from experienced developers it's more common that someone who's less experienced might make a mark weight submitter might make this mistake of doing one of these things and not realize he was doing that. Yeah, yeah, that's much more common to be a drive by or someone seeing it someplace and copying it. I see okay to to so come from a less experienced. And that makes sense right I copied some code that was seven years old, but it works for me and I copied it and therefore now I've got this thing that violates one of these principles. Okay, good. All right. That was really it. So, if you see code like that, maybe request a change. I think that will benefit us down the road. When we're far enough along to actually activate it. And now is big enough that it's worth putting in the contributing guide. The style so in the contributing page of Jenkins core that no new code should use in line in line JavaScript in the eval. Right, so that is something that I plan to do next. And I hope other comment can you see this agree there. Just like I phrased it at the beginning new or substantially altered JavaScript code obviously if you intend it to fix formatting. It's not your code, but anything more than that should probably be adapted. So it's, we're still not far enough along to put it in as a as a lint check. Is it even feasible to do these things as some sort of lint check or not really core itself isn't ready yet. And what what we could consider in the future is having stuff like the plug in injected tests, or just test cases in core that visit some pages in Jenkins and look for CSP violations so that's definitely doable. It's just likely doable to not accidentally reintroduce something like that but there are still tons of pages left so most of the UI sort of is fairly clean after my recent pull requests at least including the open ones, but it's still a way to go. You could even add it now or soon, which just ignores any that you haven't got to yet as well. The fun thing about that is, it's really difficult to ignore stuff that's dynamically generated JavaScript because you don't have a checksum. You barely have reliable substrings. And so yeah that's that's still quite annoying. Just ignore jelly files that you know to have issues, but because the test fails. So whatever test that you would write was the reason that you wouldn't write it now to stop introducing new places. Every site panel of every job page that has the build button has the problem, and I think it's also in the context menu of the job. So this is where we're currently at so we're not there yet. Okay, so not yet ready for widespread sanity safety checks kind of thing we've got to get through this initial debt repayment before we can, before we can turn something like that on right. Especially the build button is a painful one because of the context menu, which also made me think I think of the context menu. When I brought up the dividing line on the plugin manager UI and earlier topic. Because I thought I had a fix and then I saw where where it's being displayed on the Jenkins UI somewhere completely different and then I didn't have a fix anymore. So thank you that I apologize but I've actually run out of time here I propose that we call an end for today we've hit our hour and I need to be prompt to my next meeting. Any hot topics other hot topics that need to be in in this last moment before we end. We're running. I'm, I'm currently doing an audit of accessibility in CI. Okay, great. Oh, there may be some not knowing what that bullet point. Christina, do you do you read, do you read German language because we've got this accessibility assessment that was done for Jenkins that was done in German language would it help you. Sure. Okay so Mark's use, and they were willing to share it so was that for, I assume it's for the open source. So it was done for Jenkins. Yeah, so I used to run a lot of previous life so I'm looking forward to tackling CI but since there's not much of the line gets pretty nebulous and she'll be some crossover into. All right. We'll see how it goes. So I propose to end for today I will post the recording I hope later today or potentially it'll be tomorrow today's a little busy. Thanks everybody. Thank you.