 Welcome, this is the Jenkins Governance Board meeting. It's the 18th of May, 2022. Topics I've got on the agenda include news, action items, Sheikot Africa Contributon, Google Summer of Code, forums and topics, any other items that should be added to the agenda that aren't on it? Nothing I can think of. Okay, great. All right, so let's do the news. Look at all the people. Exactly, isn't that wonderful? So I'm gonna start with the news section then. So yesterday we had a plug-in security advisory. Thanks to the Jenkins security team for posting it. Number of fixes, interesting things, CSRF, et cetera. So vulnerabilities in various layers, credential exposures, all good fixes to have, cross-site scripting, one glaring one was the Git plug-in released with a problem in it on Windows controllers. The release has been delivered to fix that problem. Sorry about that. Obviously didn't test well enough before we released it. Next piece, June LTS is coming, June 15th of 2022. Alexander Brandus is the release lead under the guidance of Tim Jacoma's release officer. He's delivered the release, the first release candidate and it's ready for test. The change log and upgrade poll request has been submitted. We've got still a blog post that needs to be done and some other work, Kevin Martins is taking the lead on that effort and great to see his work on that one. Next item on the news is Java 11 will be required. No more Java 8 beginning June 21, 2022. So that release we expect will drop support for Java 8 and Jenkins. That's in preparation for the September LTS that will drop support for Java 8, all as part of Jenkins Enhance also 236. We've got Jira Epyx that are tracking the work thanks to Basel, thanks to Adrienne Lecharpentier and others, this Java 11 phase five is a great example of a wonderful way to track things. I've been just amazed, shows how we're making progress and you can see similar results for Java 17. Really a cool use of Jira to help us see where we're at. We've got an open topic on Jaxby that's making really good progress, getting ready for the Java 11 transition, plug-in maintainers are receiving pull requests, asking them, hey, please, could you fix this so that you're not broken when we require Java 11? Any questions or concerns on those three items of news? No concerns, but I want to thank all of the plug-in maintainers that have been so responsive and doing releases for Jaxby compatibility. That's highly appreciated. Agreed and that's a great experience to have people respond to a request for, hey, here's a change, could you look at this? Excellent, thanks very, very much. All right, next part is the action items and I have the action, two action items that I've made no progress on and won't make any progress on for a while. Fosum funds transfer from Tracy Miranda and Linux Foundation funds transfer from GSOC. Alyssa Tong on the GSOC one has provided me some helpful pointers so I may get further traction there over the next month. I asked CDF for a survey participation count on their survey and their answer was, right now they have only 18 people registered for the survey. They have not sent the survey yet and not likely to send it until after CDCON. So there's still time to register for that survey to help them know how they can best help our project as they provide us services. If you want to increase responses to the initial signup, I think the two things are we should, we should blast another, the same thing you did already and just indicate why you should sign up because I definitely haven't signed up and I'm not really sure why I'd want to. Good, right. So let me, and I think there it's a good thing for me to Mark request that info from Michelle and then send it out. To that end, it might be helpful to list the services that are already being provided by the CDF. For example, one that I'm aware of is the JIRA hosting which is very valuable service for us. I mean, I rely on JIRA to do all of this project, tracking work, and maybe if we enumerated all of these services that might help people to think to themselves, oh, I use that, oh, I rely on that, you know, maybe it would be good for me to provide some positive feedback about this. Good, yes, good insight. I wonder if it might also be worthwhile share any services they are considering offering because that may be the other is, oh, are they going to ask which services are most valuable? Then that may give us other insights. Good, any other items on the action items? New meeting time, our favorite topic. New meeting time, yes, very good. So Gavin, go ahead. This has been on three quarters of our agendas over the year, but it was requested that the meeting time get shifted, what, three, four hours ahead to, I don't know, once I don't know, but if they requested to move the meeting time a little bit up so that some of the EU people don't have to deal with shifting work to get here. Yeah, so I'm gonna ask those who are here, any objections from any of you if we were to shift this meeting three hours later for those who are from the EU for their benefit? Later or earlier? Later, truly later. No, earlier is bad for them because it collides with them. They intentionally wanted to put it in, in what for me sounds like the dark of the night. Bruno, with you being in Europe, it's probably your best gauge. What time is it now for you in Europe, Bruno? It's seven p.m. Okay, so the proposal is would put it at 10 p.m. European and that's after Oleg's putting his little one to bed and gives him time to do it. So it's intentionally later in the day that way. Okay. So I take, so let me call for, I need to see thumbs up to say yes, if you're okay with that suggestion for three hours later. Either way, it's in the middle of my work day, so it doesn't matter to me. Okay, great. Okay, and I'm gonna assume those that I don't see a thumbs up for that you're okay, you're not casting a vote. So we're gonna say that yes, this is approved and Mark move the calendar item three hours later. Good, I will do that. Any other action items I missed? Okay, next topic then. Sheikot Africa Contributon. We've entered the final reporting phase that will last for roughly two weeks. Then we'll do a concluding blog post on Jenkins.io. The posts on community.Jenkins.io are a reminder, how much easier it is to post to community.Jenkins.io than to create a blog post. So here is peace, peace Okafor's concluding post, nicely formatted, good head headings, et cetera. Here's the post from Nafisa, our project manager. And we're looking forward to four other posts on community.Jenkins.io because it's public. They'll also use the same post for their submission to Sheikot Africa for their final project summary. So Gavin, thank you again for community.Jenkins.io. I mean, it wasn't me, but yeah, thank you. Google Summer of Code was next topic. They'll announce their selected projects this Friday, May the 20th, 2022. We're quite optimistic that Jenkins will be chosen. We had four or five projects that we had submitted as ideas with mentors, with good solid project plans, with good candidates. And so we hope, we don't know how many of those will be chosen and we won't know until they officially announce, but we hope that we'll be chosen and we look forward to running those throughout the summer. Any questions on Google Summer of Code? Okay, next topic then. Gavin, forums and topics. Yeah, the only one that came to mind, I have not been totally engaged this week, is that the crowd in discussions, there was eight plugins currently using it. And that looked like really exciting to me. I think it is. And if we look here, Bruno has been doing great things. You can see his icon here to thank you very much, Bruno, for the French language translations. We see multiple contributors, not just from Bruno, but from Chinese native speakers offering translations. So the experiment's looking quite good. Now we still need, we've still got some gaps there. One of the gaps is internationalizing a plugin is not as straightforward as it should be because the documentation is behind what the current preferred practices are. And so one of the things I hope to do is in the Dock SIG, we hope to put better documentation about that internationalization process so that people do it right the first time as they work through their plugin development. Okay, Mark, if ever you think I can help on this subject with your peer working on that, count me in. Oh, good, thank you. Yes, Bruno. And I think we'll be discussing it tomorrow during Dock's office hours. So if you wanna join us for office hours tomorrow, that'd be great. You're trying to, okay. Great. And Gavin, any other topics there? I know we've got contributor summit from my side. Nothing comes to mind. I know Basil, was it Basil or Basil? Basil. Basil, Basil had the whole thread about Java 11 that you touched. So there has been a couple posts across mailing lists about interest in translations, but they got their own weird location. So I don't think they got touched. Yeah, the Dock's mailing list had a comment about translations tools. Yeah, and I think some of those are actually as much internationalization as they are local as they're in translation. So yeah, good. I do notice there is, the last few versions have had a bunch of Jenkins have had some issues on the forms. People have complained about a couple of issues over and over again, mostly not reading the upgrade guide. So I don't think there's a lot we can do about it. Yeah. Well, I monitor the JIRA Regressions dashboard pretty closely. So if people are experiencing a problem, they can vote on the issue in JIRA and we'll actually see it on our dashboard. Yeah. There's a lot of watchers. The thing is people are like, especially in chat going, I have this long stack trace and my thing doesn't work. And you're like, yep, sounds like a bug. You should report a JIRA. And they're like, but I want to fix now. And you're like, yep, you should report a JIRA. Yeah. I've often found myself linking to the page on filing issues, which is a good place to start. And I mean, on a personal level of that, I do want to write up a can response for the forms that maybe even for the chat. Oh, there is a board topic. Yes. I want to create a can response for just something like, I see you have a difference between environments. These are how you can debug it. Like how to print and stuff like that. But, and that's not a bug per se. That's just something, you know, stop gap. But there are, I've seen a couple posts last couple weeks about people saying so and so it's broken and you're like, yeah, you have to. So maybe we can make, I don't know how we could do it on a board level, but try to make it easier for people to know that bugs are probably better than chat rooms. Yeah. I foresee this being a continuing issue because we're making a lot of changes in the next LTS and the UI. And also with Java 11 being required, I could see that being another possible generator of support requests. And Mark has been saintly in how many times he's replied, do not download a new Warfile, run your YAM update. Do not download a new Warfile, run YAM update. By the way, do not download a new Warfile. We saw one on chat today, which is someone was logging into Docker containers and updating their Warfiles on Kubernetes. And you're like, how did you even get to that level? Yes, yes, that was, aren't those kind of things really cool? You decoded a way to go inside the container, replace the Warfile in the container. Wow, that's cool. Let's stop doing that. That's not the word I would use. Yeah. But there was one, so I just had a second to go. Oh, there was a thread on helpdesk I saw a while ago about bridging IRC and Gitter so that people don't have to hang out in both. And I think that's actually a good idea. The reason I think the board should be involved is, I don't know who other than Mark has the men to Gitter. And I mean, someone with the men to Gitter has to be the one that approves and talks to people. So I suspect because I'll end up doing the work, I should probably get a man to Gitter. Okay, yeah. So this would basically allow the Jenkins or the Jenkins infra and the Jenkins release channels on IRC to be visible through Gitter as well. That's not the point of it, but it could be done. Yes, the point was to make the Jenkins IRC channel and the Jenkins Gitter channel talk to each other so that someone who wrote in one could see it in the other. I see. Because right now it's split and some people are in one, some in the other. Got it. Okay, thanks. Anything else on forums and topics? Community topics. When can we delete Blue Ocean? No, that's a bad question there, Clint. Wait a sec. First we need to delete Evergreen. If we're talking about deletions, let's delete the things that are actually not being used. Evergreen was actually shut down a year ago. Yeah, it's still on the website. I was just looking at the forum posts and someone's saying about Blue Ocean was broken or it changed the URLs. I'm like, yeah. Okay. All right. Anything else? No, but also, I kind of want to push heavier for forums instead of mailiness. I'm trying to centralize. We've had an ongoing issue for years where everything is so spread out. There's Stack Overflow, there's IRC, there's Gitter, there's forums, there's mailing lists, there's websites, there's Twitter, there's LinkedIn, and anyone needs help picks one and probably not the right one because only half of the people are there. As much as I would love to see the developers, mailing list move to the community site, I'm thinking it might be worth just moving the other ones. So like docs right now, it's pretty heavily not using the mailing list. So it might be a good one to be like, hey, we're shutting down posting, please use the forums. Or maybe there's ability and discourse to do a read-only clone of the mailing list. So anyone who posts to the forums will get a moderate post to the topic. I don't know. It's just something that I'm like, at some point we should probably have a discussion about this. Good. But like infrastructure, the mailing list isn't really used. Most of the stuff is moved to help desk and then a few things left over in the info list. The UX one is definitely not used. And those are the ones I'm on. I'm sure there's more mailings than that. That might help explain why I didn't get any replies to the last posts that I made on the UX and docs mailing lists because I wasn't aware that I needed to make those on the community site. I don't know if the community site is used either for them, but they're almost entirely in the office hours or the getters. So at the very least docs, the description on the list should be updated or a post to it, a pin post maybe or something just to explain what people are wanting to do with it. Yeah, so I could see putting a tombstone posting on the docs mailing list saying, hey, we're moving to community.jankins.io. That one I could see easily. Same for infra and UX. Would that be enough? Or Gavin, are you envisioning something more? I don't know. Was this something I was idly thinking about? I think a tombstone would be a good first start. That tombstone would only really be effective if we also made those lists read-only because otherwise it's all too easy to not read that tombstone message and continue posting without realizing that you're posting into effectively a definite channel. We can look into it. There might even be a way to do like an auto responder to say, hey, this mail list is retired. Yeah, now in terms of central, I'm not sure I'm really effective at managing lists, mailing lists kind of communications on community.jankins.io. How does that work, Gavin? And would you be willing to do a tutorial at some point to guide me through? Make it any complicatedness. We have a category for docs. You're already using it to post meeting minutes. Just that's it, right? Oh, okay. So just anything posted to the... So, okay, so now I've got to show it just to be sure. So what you're saying is anything that has... If I look for DocsSig. Yeah, I mean that works too. The thing is... Some of the SIG docs. My concern is that if someone has a question or they post it in the wrong space, it's impossible to do anything about it. We had that issue for the longest time. People would post it in for a mailing list asking about their install. You're like, nope, you got the wrong spot. And that's it. That's the end of the conversation. At least putting it to the forums. We can be like, nope, we're moving into this category. We can ping someone by putting it all in one spot. It helps. Someone has a question about the Git plugin on IRC. Mark's not there. I could be like, hey, join Gitter and hope for the best. But the more we centralize it, the less we have to redirect users later. Right, okay. So here's an example of a thing that was originally started as one thing, but became another. Good, okay. So SIG docs, we can tag them that way and they'll be there. Just any posting here that's docs related would be okay. And we would put the tombstone on the Docs mailing list. But I think about the tags that you can be in multiple. The categories you can only be in one, but you can move categories really easily and very visibly. Okay. And then like I mean, I could do Devon at some point in the future. But the nice thing about this course is you have very fine notification controls. So just for everyone's thing here on the right of their page, you have the little bell. Right. You can actually control how your notification will be on this tag. So you're actually selected on the SIGs Doc tags. You could be like, I'm watching that tag and you will get every email about anything in that tag. Or you could leave it at first post. So the first time someone posts in that tag, they get an email, but not every reply to it and so on. Like you can control it. Like it's all manageable in your preferences as well. You don't have to go to each tag and do it manually. But like it's very customizable in the same gerosense of it, right? And that's one thing that the mailing list don't have is you either get all of it or none of it. So yeah, I just think centralization is better, not necessarily that the forms are the best place. Great. I like that. We could make a similar comparison to the multiplicity of issued trackers that are in use. Because there's a lot of, it's hard, for example, to manage projects when those projects span both JIRA and GitHub issues to track the same projects. Whereas if we're using one system instead of being just spread out, we can track everything. Yeah, and we were trying to abstract that as much as we could in the plug-in site because people were doing it anyways so that you can do very easily, you know, have list of issues. You don't have to think about where it is, but I agree. That was one of the issues we, I mean, even years before most of the people on this call are around, people were wanting to use GitHub and were like, it should be one or the other, not both, both of the mess. And the same with chat, same with mailing list, same with everything. And as a very new Jenkins user, I find it really difficult to interact with people within GitHub and there are so many channels. I think last year when it was a contributor summit, you listed 97 GitHub channels, I think. It's just impossible to do something salesly with that many channels. So having a more centralized system, yes, would be very useful for a young timer. I think so. So I'm going to keep trying to push it, but I'm also not aggressively doing it and we probably could get more aggressive about it. Well, so it feels like a great excuse for a topic for docs. Docs office hours is a test case to say, hey, let's talk about it and see if you're really ready because you're right. The docs mailing list is quiet. It's certainly not the central place for conversations about docs. That's office hours and asynchronous communication could move to community.jankins.io very easily. Yeah, okay, here we go. Here's my favorite, I'm going to put it in chat. There's the thing I collated last year. So like I said, I want to try to centralize that as best as possible because it's impossible to know where to go. Right, yeah, that number is good. For all the Gitter channels, I'm sorry, are they called channels or rooms? I guess they're called rooms. Maybe it might help if we define a naming scheme. For example, x-sig is a namespace for these official special interest groups. And you have like x-plugin. So we could name these chat rooms or name these rooms after the corresponding repository or organizational entity. And that might help put a limit on how many of these things there are if they're more closely related to some other entity. Yeah, if it was purely, if I could be like dictatorship and choose, it would be a Gitter matrix for any live chat, community site for everything else. And then, I don't really care but JIRA or GitHub for issues. Like I said, one or the other. Honestly, if we could integrate things a little bit better, we probably wouldn't even have to worry about what the answer is. But it's so hard, it's be hard to dictate this because it's so spread out. So the best we can do is fix the outliers and make the more people who are using community site the more we can put onto it and the easier it is to migrate things to it. So that's why, because Mark likes it, docs is my first order of business. But yeah, I think renaming channels if we can, I don't know if we can even rename channels. But I don't, well, I haven't seen a lot of growth in the number of Gitter rooms that are out there. It's rather that there are still many. I keep 10 or 15 on my screen. So I'm not seeing a naming convention helping much as much as inspiring people to go elsewhere for useful things. Let's just say a new Gitter channel is created today, Mark. How would you find out? I would not. So how would you know if there are new channels or not? Oh, fair point. Okay. Yeah, I mean, I don't know. I don't know when 79 was calculated. I don't know how we did it either. So yeah, either way, it's just, this is one of the things that's been bugging me for a long time and I don't have a solution for it. And the only solution I have is final people as best we can into one spot. Let's do the experiment. Let's try it. I like it. Shutting down, putting a tombstone on the docs mailing list should be pretty easy. And if it works and we make it read, successfully make it read only, then we shift the conversations to community.jankins.io when we're set. Yeah. Yeah. Yeah, I think in the long term, we need to come up with a plan for the issue trackers because it's too difficult to do project management with a split view of the, and there are certain features or areas of functionality that are present in some issue trackers, but not others. So I think that's a really for any problem that we're gonna need to deal with at some point. I don't have any thoughts on it right now. I can see this becoming more of an issue in the future. Yeah. If you search the dev mailing list, there are big, big, big topics about which one we should use and finally people are just like, we're gonna use both because we can't decide. Right. And I think it is a valid topic and it's a good dev list topic to bring as we need to discuss further. It's the dev list has been the place where it's been discussed in the past. Yeah. The only solution I can see, and I hate the sentence so much, is moving project management out of JIRA, so it could be, you know, there's gotta be tooling that supports multiple systems, but also I don't wanna support multiple systems, so. Right, and then you just hit it, Gavin, is, well, do we really have, yeah, topic for developer discussion. Yeah. Any other topics for today? Yeah. All right. If no other topics, I'll stop the recording. Thanks everybody. Cool.