 Welcome, everyone. This is the Jenkins Governance Board. It's November 28th, 2022. Welcome to new members of the board, Uli Hofner, or new members of the board beginning December 3rd. Uli Hofner and Alex Brandis, special thanks to Gavin and to Evelina, who will be exiting the board, and we hope will stay deeply involved in Jenkins and continuing forward with us. Topics I had, News, Action Items, Elections, Governance Board Meeting Time and Date, and CDF Outreach Reboot. Oh, oh, and then we had the usual topics, which is CDF topics from Oleg, if he's available, and then Community Forum, and that's from Gavin Logan. Any other topics that need to go on the agenda for today? You skipped that part, but the Governance Meeting Time would be a topic I... It's important for me. Yeah, and I just want to be sure we have it on the agenda. We will be sure we address it. Absolutely, Uli. Very good. Thank you. So that one's on the agenda. We'll make sure we get to it. Any other topics that we need to add to the agenda? Okay. Then let's go ahead with our beginnings. So by way of news, the one item of news I had is this Wednesday we have 2.375.1 with thanks to Alex acting as our release lead. Thanks very much, Alex. And it looks good. Testing. My testing has been running for almost a month with 2.375, etc., and the release candidate for two plus weeks. So looks good. Any concerns from anyone else about what's coming out in that release? Okay, next item then is action items. Action items, we have several that carried over from last time. Only to follow up on this, I had failed to do it last time. We'll do it this time, create an empty agenda entry for the next meeting after the end of each meeting. We're also, we discussed in last governance board, switching from the concept of sub-projects and special interest groups to a single concept working groups. And I'll submit a poll request to www.Jenkins.io to match that. Oleg's got the action item to send a proposal to Rick to retire the Chinese Jenkins site because it is badly out of date. Then Gavin and I have the action item to archive the governance meeting notes to a GitHub repository for permitted archive because if you look at the scroll bar on this Google Doc, you'll see that this is over 100 pages long, it's becoming unwieldy. So we want to switch it to a more permanent location than Google Docs. Kevin Martins has the action item to switch from using a Google Group mailing list for Jenkins Docs to use community.Jenkins.io. He's accepted that and will work on it. Can I ask a question about the topic before, because I think you are publishing the agenda after the meeting in our community. So I'm wondering why we should record the same thing in this document additionally. Oh, and I think the answer there is archival copies are not in archival copies are not on meaning historical copies from years ago are not on community. There's two things. There's one is that things communities not really a hard concrete source of truth and also we don't have all the old meetings. So anything before like March or April isn't in is an archive anywhere but this to Google Doc. Yes, I understand for the old things but starting from now, I think it would make sense to just use the agenda. And after we publish the agenda to the community, there is no need to let it in this document here. Or why do we have two places where we store the same thing? This is something I'm not understanding. That wasn't discussed. We only discussed the older ones. Okay, great. Okay, so the the concept still holds. We could consider community.jankins.io the archive for the future but we need an archive of the history and that archive a GitHub repository is not bad, right? Good. Thanks, Gavin. Any other any other items on that one before we go forward on other action items? So just to you, did you create a repo or am I creating a repo? How are we splitting this up? I haven't I haven't created one and either you or I can do it. I'm fine with either. I actually forgot how to make action items in Google Doc. Isn't that how you do it? Almost. You go like this. We oops highlight click like that. The email unfortunate can only assign it to one. That's fine. I'll take care of it. Great. All right. Okay. Anything else on that one before we go forward? Okay, next was a proposal to create a documented statement on jankins.io about web application server support. Do you see Jesse's reply three minutes ago? I did. I was very impressed. On the one hand, we've got quite a number of users who are saying, hey, it works for me. And on the other hand, we've got core developers who say, none of us tested, none of us verify that it works on these other containers. We're not willing to support it. And Jesse Glick just posted a note saying, and there are some crucial things like web sockets that are expected to not work. So it's an open point for discussion. It feels like it needs more discussion, though I think a pull request may be the way to do that discussion unless here in the governance board, you feel like I need to propose a JEP officially dropping support of the thing. Should we do the discussion? I think on the download, you can go on the download page and anything other than the one that we're using is not tested. And then it sounds like they're based on the previous JEP. There should be a JEP to kill the other ones. I think those are two different problems. Good point. I like that. So we can state the current situation, what is and is not tested, what is tested and what is not tested. And then the end of a separate task to decide the future. That's good because I like that. That's one that Basel had guided me on previously when we were describing operating system support. His preference was, let's say what we actually test in automation. And that way people know, hey, this is covered by automated tests. If it's not covered by automated tests, we should state so. Good. All right. Thank you. Any other discussion on the web application server support? So the Tomcat, the glassfish, the web sphere, etc. Which servers are people still using that we want to consider dropping support for? Is it just Tomcat and Wildfly or other others? Tomcat and Wildfly are the two most popular that I've seen. Gavin, have you seen mention of others? I think I might have seen glassfish ones. Is that part of metrics? Do we have that data? I'm not aware of it being part of metrics. Is that gettable? Could we expand the telemetry stuff to report that information? I'm going to say why not. Sure. I was going to say also for me, so we're going to do one PR that just makes sure we state what the current state is. It's probably worth mentioning on there that saying unless we find a maintainer, it's going to get, no, it's worse as bad as, never mind. Well, I think stating the current situation is honorable and fair, right? I was thinking about like, do we want to write down, unless we find a maintainer, it's going to get worse. But that feels gross and I don't want to state that out loud. Right. I don't think we need to state the current situation plus offer the threat. The threat will come by virtue of the separate task to decide the future of web application server support. Because I think Jesse's right that if we don't support WebSocket and there are probably other things we don't support and our core developers don't develop on it or test it, it's tough to claim support for it. It's tough to argue that it should be supported even. So, Mark, for that list of support, for that support matrix, were you considering something like what we do for the Linux support matrix where there is three levels supported, patches considered and unsupported, was that the structure that you were thinking of using? That was the structure I was considering and what Jesse's comment back was, hey, I, he thinks that they're really only, we support it, we test it, we support it and everything else. And that's where I think there's some discussion because I was thinking three tiers and the way Jesse described it, maybe what I can do is show Jesse's description or we could have people read it separately. It's a post to community.jhans.io. So I think his description is effectively two tiers where there's only supported and unsupported. But I think a three tier system is needed for no other reason than a lot of people are already using this and it would be unfair to them to move them from, I think the status quo is in fact three tiers and it would be unfair to collapse the second and third without some prior notice, which is kind of what we were hinting at with the concept of having a separate task to decide the future of web application. Like, to me that task feels like collapsing tiers two and three, which is the status quo. I don't think that's a bad idea, but I think that would need to be accompanied by communication over some long period of time, like warning people that they're going from being patches considered into being completely unsupported. Yeah, I like that. Go ahead. I think it's worse than that. I think that the non-existent JEP would be to remove two and three entirely. Like, only supported. Right, we're talking about the same thing because tier three is unsupported. Oh yeah, but I think Jesse's point was that Tomcat would be flat out dropped. Yeah, but for now, yeah, I think before that even happens. I mean, that's part of the JEP is how to deal with it, but administration monitors say, hey, you're on an unsupported container. In the future, this would go away, that kind of thing. Yeah, but for now, I think the big thing is we get form topics and now I've identified two problems with Tomcat alone, and we have nothing to point to and be like, here's some known problems. This is why you shouldn't do anything like that, even if it's just a blog post would be probably good enough. Right, so I think tier one would obviously be Jetty in the form of Winston. And then I think tier two, which is patches considered, I think that would be that would be using Tomcat or Wildfly, maybe that third one, maybe Glassfish in with all of the asterisks, all the prerequisites, like use the right version of Java EE and set Jenkins home the right way. And by the way, WebSocket doesn't work, all of the asterisks, I think that would be tier two. In other words, we don't test this, but patches are welcome. If you want to document this or if you think it should be improved somehow. And that's kind of matches our Linux policy, right, Mark? It does. Those are the three kinds of layers. It's tier one is, hey, we test it with automation, and we expect it to continue working. Tier two, we don't test it with automation, but we're willing to consider other people's proposals to patch something. And tier three, vendor doesn't support it, we therefore flatly will not accept any patch to do anything for it. I think tier three in this context is like using Java EE, the wrong version of Java EE, which we just don't support at all, or any other certainly container besides those two that we met, those two or three that we just mentioned. Does that seem like a good analog to the Linux policy? Yes. Yeah. So, Gavin, is having a clear statement like that, do you think that would be sufficient to clarify the situation for users? Honestly, even if it was on the Dallas page, this says we only test Jedi, that'd be good enough for me. Okay. Yeah. And I'm prone to, so I can, if this three tier pattern doesn't get agreement from people, I'll certainly submit a second pull request with the stating that we don't test, because at least that's describing it. I like the three tier because we've already got Windows, Linux, and what is one other, oh, and Java versions that are on the downloads page with a matching page that talks about what we do and don't support, or what we do and don't test. Anything else on the application web application server support topic? Okay. Any action items I had missed? The next topic is elections. So, welcome, Uli. Welcome, Alex. New board members beginning December 3rd. Thank you very much in advance. Two years with us. We're delighted. Uli, returning. Alex, first time member of the board. Great to have you both. I've submitted a proposal to change the rules for next year's elections. And that proposal has gone out to the Jenkins developer list, and is proposed to Jenkins.io as a pull request. Any comments or concerns for new, for others on what's proposed there or how to deal with it? Actually, I haven't read it yet. What is it proposed about? So, today, the rules prevent a second CloudBees employee from serving on the board because we have the overarching rule that, no, we cannot have any company have a majority of people from a single company on the board. So, because Kosuke is considered affiliated with CloudBees, even though not ultimately employed by CloudBees, he counts as one as a permanent board member. I count as the other, and therefore, we couldn't have a third CloudBees person. What this proposes to do is says we don't count the permanent board members affiliation. We just say we may have up to two elected board members from a single company, no matter what their company is. So, it still keeps us that no company dominates the elected board positions, but it ignores Kosuke's position as a permanent board member in that accounting. Did that mean that our company would have a retool against everything? No. If Kosuke were somehow to behave in a manner that was contrary to the Jenkins project and got involved, then yes, that would be the risk that CloudBees would. Doesn't Kosuke already have video powers? I'd have to read the bylaws. I don't think so. My sense was that, but he's certainly used as an arbiter of conflicts, right? When we have something where we don't come to agreement without him, he can help us resolve conflicts. Uli, back to your question. Is there a risk? I think, yes, the reality is there is a risk. I think there is a risk, but actually, I never have seen anything bad from CloudBees right now, so it's just a risk. Yeah, just to add something real quick to that. I mean, KK has a permanent seat on the board and two CloudBees employees, and you said two employees from one company. I wouldn't subject that necessarily to CloudBees only. We don't know what happens in the future and we know from the past that not only CloudBees members, we have board members, CEO Gavin, CEO Oleg, and other members from the past weren't CB members. We definitely agree with Uli. I think we should keep that rule somewhat of up because there's always the risk that more people get involved in the community just to push Jenkins or just push the project into a direction we possibly don't want to go into and would be simply get overruled if there are three or even more board members by one company. So for context, Mark's thing is specifically removing the restriction for elected. So I mean, all of us on this call, all the board members on this call are elected, right? Koski is the only one that's not elected. So all he's suggesting is dropping that requirement from the non-elected members. So that means Koski would not be included in the restriction of only two members from a single company. I'm going to say flat out, I don't think this should be decided tonight. I think Mark sent out the email and I think it should be discussed but the other thing was the reason it came up was we were having total funding potential board member candidates. A lot of the community members right now are either not interested or from CloudBees and that really restricted it. It was considered you could only have one CloudBees member on the board. I think another factor is that Koski has been steadily shifting his focus over the past few years since these rules were originally written. He's gone from doing every single weekly release and being an executive at CloudBees into kind of shifting his focus to his new company and we've slowly been transferring all of the repositories from his organization into the Jenkins organization and there's been this very natural shift of focus for him onto his next endeavor. So maybe we're trying to do two things. We're trying to honor his foundational contributions in the past but also acknowledging that the project is functioning independently in this next phase that includes less and less of Koski's involvement as each year goes by and I think that's a very natural and healthy evolution of the project and one which Koski himself has written about many times that he's pleased to see things graduating from his nest into their own blossoming self-sustaining system and I think he's personally written to me when you transfer his repositories that he's happy to see them being maintained by other people and to not be the bottleneck and to see these things kind of graduating. So I think that's another big part of this. It's kind of honoring Koski's past foundational work but also acknowledging that he's got a lot of other areas of focus now and Jenkins is fading a little bit into the background for him which is I think a very healthy and natural thing to happen. Thanks. So Uli did that did that address your comments and Alex likewise? Well I understand the reasoning and I think we can continue the discussion on the mailing list. Yes yeah yeah and I think it's not about Koski it's about 50% was 50% so I think Koski did not yeah yeah he did not really participate in the last two or three years so I think we only have four members and if a company has 50% now they can block everything so that's a thing we should be aware of and that's for me a risk that we now have a situation where we would like to decide something and a company can say no we don't want to have it and then we have a situation where we have two seats from one company that can say everything no and that's a risk for me I'm what I think it's not so good for the project so that's not changing though I mean right now any other company can have two board members? Yeah it's not about cloud business it's about every company. Yeah but I mean that's the case right now every company that is in CloudBees is allowed to have two employees on the board the problem was because Koski is permanently on the board CloudBees can only ever have one other person and Koski is not actually working with CloudBees right now he's affiliated but not working with and that's what Mark's changing tweaking the wording to make that distinction. Yeah but I think we should make us aware that Koski is not participating anymore so maybe the rules should be changed anyway because another company can come in and say okay let's have two seats and then we can block every decision so maybe change the rule overall. I think that's a valid point but I'm not sure actually that risk is real in this case because if let's say an arbitrary company gets two seats on the board that's only 50% of the four active members if there's a conflict Kosuke will step in as a board member and resolve the conflict so we still have we still have a safeguard in that Kosuke is a safeguard and he he actually was expressed his opinion on this this proposal separately to the board in board emails and said that he he favors this as one alternative so so for me I think it's actually a reasonably safe thing even in the scenario of your concern Uli. Okay okay that reminds me though do Uli and Alex want to send me an email and I'll add you to the board mailing list just whatever email you want added to the list I will add. That's fine I'll send you and then and then you can look at the history if you feel like it. Right very very good well and and I had an action item from our meeting two weeks ago to get a see if there was a private statement that Kosuke was willing to share in terms of his involvement with CloudBees right now I've got that statement and I'll send it to the board for all of you to read as board members. It's not something I'm ready to share publicly I didn't get authorization to share publicly but I think it states in general terms his involvement so if to Uli's point we want to change the rules in terms of whether or not Kosuke is considered affiliated with CloudBees or whether or not we want some other terminology in terms of affiliated or employed by or something that statement from Kosuke may help guide those discussions in the board. Okay fine great all right so so that one anything else on the proposed rule changes will continue discussions in the mailing list allow those contention can those discussions to reach their logical conclusion whatever that may be hear the voices of community members and bring it up again in two weeks or in four weeks in our next board meetings. Great okay next item was that um elections are complete thanks to Gavin and to Avelina, Welkomuli and Alex and permission changes so Alex or Gavin you said send email to Gavin to become a board a member of the board of the board mailing list are there other permissions that we need to extend to board members I don't remember the many ones come to mind are github teams so both Jenkins CI and Jenkins Infra mostly to approve any changes to jinx.io that needs board approving um all right right technically the CLCC and CLA stuff but that's still messy I'm just talking to make sure I can add I don't think I can add people to oh I can yeah I think we can we can neglect the CLA and ICLA stuff for now at least until we fully switch to the LFX solution because if I remember correctly only Oleg has the key to actually decrypt the PDFs so yeah Oleg and KK the only ones that do it yeah the unofficial official rule is anyone in the board approves the PR for that request and we just we just count the PR itself as the request to not what's contents of the request so yeah again once you send me the email I'll add you to the github teams as well looks like I can do that and then the only other one that I still don't have access to is the LFX crowdfunding thing but that's a bit of a mess because crowdfunding doesn't support multiple people so it's kind of awkward and then anyone who doesn't have it and wants it mark can help you set up for zoom all right right zoom meeting uh password yes exactly so the zoom account password if you need to host a host a meeting with the the Jenkins project zoom account we have a process to share that I would call it optional not a requirement for board right good okay those are the only ones oh and then technically one password though we're not really using it all right okay and then I'm going to keep an eye out for anything left over that I because when I got on the board I fought hard to make sure that I got access to the things I need to get access to but I think that's the only immediate ones great okay any other topics with regard to elections oh actually uh so community Jenkins IO IO uh all black uh Olivia and I have been admins forever I don't mind staying as the admin um but uh do we want to make sure uh all board members have like moderation access or anything like that um that's more of a discussion and not something on me but that is something I'm thinking about whether or not that should be done I think at the very least board members should be able to delete a post because I think that's when you step in for any any uh community guidelines whatever that word is uh anytime that it has to be done I think the board needs to be able to step in but I don't know what you want to do for this so I like that okay so we we had an episode what was it uh six months ago maybe where I ultimately phrased a posting that I made to community dot Jenkins IO saying I am acting as a member of the Jenkins governing board and I am declaring that what you did is contrary to community our community guidelines um and and that was me acting as a board member so I think I would love to have Uli and Alex also have moderator access just to to help with that in case I miss something Alex Uli what's your what's your opinion I think this is a really good idea so I think uh it would be really helpful to yeah to remove posts or mark them as invalid I think the same should happen for I'm not sure Gitta or I'm using not yeah actually I'm using elements to access the Gitta mail spot yeah Gitta is another issue that is hard to manage uh I'm still planning on working on that project to move everything into matrix because we have full control in matrix we don't have full control in Gitter um I don't have even access to Gitter I don't know who does I think mark might be the only person who has Gitter access no I have to you have a good actually actually the Jenkins um namespace is configured that everyone who has the right access to Jenkins CI Jenkins can administer the Gitter rooms a kind of weird concept but it starts it up yeah that is interesting okay well then there's nothing to do there okay now maybe we can create another rule in the Jenkins CI organization add people to add and make sure this role at this team can moderate Gitta or something I don't know definitely not something commentators do no I've been looking and I have I've been want to reach out but with the the mess the Twitter is in right now everything's flooded but I want to reach out to Element and be like hey can we can we get a sponsor small instance just to host the rooms so we have like uh sigagacy at janks.io instead of at matrix.org just because I think it'll look a little bit more professional and clean and then when we do that then we'll have admin namespaces and everything and Gitter can still join and everything like that but I just hasn't been in priority with all the other stuff going on right now so back to the question on moderator access Alex are you okay being granted moderator access to community.jankens.io yeah that sounds good to me okay great so Gavin you are you okay taking the action item to do that so I can do everything on this list it's and I think mark's the only one that should do zoom so you want to assign a thing to me sure you bet just do the top level one yeah yeah so got it so anything in that list mark that you don't have access to that I also should make sure you have access to not as far as I know all those things I think I think I've got them covered I think I've got access to all of them there we go okay good enough anything else on the permissions topic okay next topic then governance board meeting time and date so what I was thinking of doing is just sending out a mark to send a what do you call it a poll is there a better way to send polls I'm used to using I forget the the service I use but some service that does that I was just going with doodling or something like that that's it doodle yes I was going gather no that's a different thing yeah no that's a different thing right right trying to remember the products I use use it use a doodle poll to ask board members and regular attendees to give their their opinion of which times would work which days would work etc does that is that okay for everyone or would you prefer something different no it's fine okay so I think of the time zones we have Europe and us yes so we've got Gavin Gavin and Basel who are both on the US west coast all the way to Uli you and Alex and Oleg who are in I think it's Central European right the year Central European time mm-hmm okay mm-hmm good anything else on governance board meeting time and date oh oh I take it back I do have one more thing I propose to cancel the governance board meeting and now I have to look at the calendar to see the exact date it would normally fall between the Christmas holiday and the New Year holiday and I would like to be offline let's see so that would be 26 December any objections from others of canceling that meeting the week of 26 December it also aligns with the postponement of the LTS release so right great okay plus one Uli plus one Alex plus one mark that means we already have a majority good all right and might be worth pushing the elections for the future back a bit because this means that there's only one official meeting for the new board before you go on hiatus oh so meaning meaning next year just decide this decide this thing in January well I was saying next year instead of having the new board start December 4th have one meeting and then not have any more meetings so January it might be worth trying to see if the election ends earlier so then you can have two full meetings just throwing it out there good good suggestion all right so maybe the plus one is already wrong currently because I and Alex are not on the board yet oh oh right right so you're right I should ask okay Gavin are you okay with canceling the board meeting that's scheduled for December 22nd I mean sure okay it's not a meeting that I necessarily have to be at anymore so right exactly strange concept and Basel and Bruno I assume no objections from either of you great all right thank you okay next topic or anything else on governance board meeting time and date then it's election and installation of new officers don't have have have more than one one meeting before end of year break I mean you could also change Christmas and into your break that would also work okay yeah fair enough next topic then okay cdf outreach reboot this is just more for your information December 14 Laurie LaRusso the I believe she's the outreach leader at continuous delivery foundation is restarting the cdf outreach effort and Alyssa Tong has agreed to be there and present for the Jenkins project I'll be there as well it's just getting started Laurie is actually with JFrog and we've been working with her as well on the JFrog contribution to cloud to Jenkins and how how we're adapting to needing to reduce bandwidth requirements there so Laurie's been a great help on that we're very grateful to JFrog for her contribution since Oleg's not here I'd propose we skip cdf topics and then the next would be community forum Gavin yeah I mean it's it's gonna it's pretty support heavy last couple weeks but there is the whole thread that various people have been accidentally typed the last one but talking about how to get involved it does sound like we get a lot of people asking that so yeah I don't know what to do with this one just it is well and actually John Mark John Mark Mason has prepared a boilerplate in the form of a blog post that he and I were going to propose we also use as a canned reply here on community with some suggestions and topics things that can help people then this thing that I did here of hey here are plugins that have just been adopted diraj jota diraj sing jota and I are trying this experiment where let's give them specific plugins and say help with this plugin and let's see what that happens that way good I've got some experiments I'm doing that are in the pipeline that could be part of this that basically I think a big a big suggestion one of the most frequent suggestions that I see being given for people who want to get involved is to adopt the plugin and bringing the plugin up to the modern standards of our build toolchain and I think that that's a that's first of all something that's very much needed to keep to keep the plugin stable and building properly and tested properly and it's it's also a great way for people to get involved if they are not involved but I think one of the downsides to that suggestion is that it's a fairly specialized and difficult task that requires a lot of domain specific knowledge to to for that task to be completed by people it can be very challenging to figure out why something doesn't build properly on the latest palm if you're if you're new to the community because this is mean even if you're familiar with java development there's a lot of things that are very specialized to the Jenkins plugin system that you have to figure out and that takes a lot of time and then once you learn it you almost never need to use that knowledge again so it's just a very high investment and low reward scenario so something that I have in the pipeline is finding ways to make that easier I've been doing a lot of experiments about this um have have an idea of building a mono repo of the top 250 plugins um that would be basically building against head all the time against the latest versions of everything not even the latest released versions but just the latest commits on the main branch and basically with that idea that would that would make our pitch a lot more friendly to these newcomers because we could say hey instead of figuring out all of this arcane build knowledge that you never need to use again after this just go and find what's being done in the mono repo and apply that into the plugin so I think that to me is a much more uh friendly message than oh you'd like to get involved okay great start fixing build failures that very few people can figure out um but I think I think that if I if I I've been kind of playing around on this but I think that would be a good step and then obviously I've got much much more grand plans like automating some of this and then adding open rewrite to uh to make it even fancier but just just getting started with the mono repo to get the the hard stuff out of the way I think that would be a positive step in in the sales pitch um because that that would transform the task from being hey thanks for thanks for wanting to get involved now do something really hard now it's like oh you can do something of easy to medium difficulty and then then you can do something and and also it's I think it's also good because if we give them the the fundamental knowledge to get the build up to date um then they can focus on something that they really want to do like add a new feature fix a bug rather than something that probably very few people are interested in which is working on builds um so anyway that's just a preview of what I've been working on there's also um triaging I think there's that's always gets uh under under suggested it's just look at open bugs and see who you can reproduce them and write up uh notes about it it could because it and we could highlight the fact that it gets you comfortable in using Jenkins which means that making feature requests are a little bit easier you actually know what people do with it good yes excellent thank you yeah and I had a I had a good a really good personal experience with that one with a new contributor Jagruti who helped me with a very specific problem I was trying to duplicate on the get plugin she did a great job good good suggestion thank you anything else on the there's there's still a large number of JIRA tickets with the UX untriaged label that we could point people to and uh the process for triaging them is somewhat laborious but um I have in the past offered to help people or to teach to teach people the process that I use which is basically um to use git bisect um coupled with interactive testing to find find the commit that introduce their aggression so that that would be a great place for people to get involved in and uh if if there's questions about how to do that I could definitely share the process I've been using good I like that a lot let's move on yeah next topic okay yeah I didn't know to title this one uh there's just an ongoing discussion everyone has their opinion on spacing and so this thread keeps going um Billy's been doing a great job of managing and suggesting but I figured it was a non-support request that I should mention yeah that is this is a good one it's a it's a good topic for ongoing discussion I expect some more noise from the release this Wednesday because there's an accessibility improvement that makes one of the things that used to be a clickable link no longer a clickable link and it it does improve accessibility it was intentionally discussed carefully decided but I'm expecting that there are going to be some users who say hey where's my click that I used to be able to click good and totally on a selfish I love it dang I included the newsletter because I'm very happy that it exists so Alyssa has done a oh I pinned the wrong topic groups I reached a request to anyone who wants to add anything to the member mailing list there's an open post for it and you know a link to the past September and October and these others yeah so I an IO IO for several I'll I'll get some submitted there thank you very much for starting that and thanks to Alyssa for submitting it thanks also to Bruno I believe Bruno you've been helping with getting the pull requests all the way to the Jenkins blog right yeah just a little bit but yeah great any other topics Gavin I think I'm surprised I'm hoping the newsletter kind of replaces this whole section so yeah great all right and are there any other topics to bring to the to the board as a whole okay then I'm gonna go ahead and stop the recording thanks very much everyone for being here