 Okay, we have been recorded. So welcome to the Jenkins governance meeting. Today is the June 3rd. So we have a number of items to discuss today. Thanks to everyone for joining this meeting. So please set yourself to the list. Keep the discussion. So I suggest we follow the agenda we set up during the previous meetings. So we'll just news, then our topics suggested by contributors. And yeah, after that, if you have time, we can discuss more items. And if you have a topic you would like to suggest, just put it in the bottom of the list. So let's start from updates. So the first update is about your UX hardfest. So if you, yeah, we had one last week during this hardfest, we had actually 54 contributors. And we did a major progress with user documentation and with some stories related to Jenkins user interface. So particular achievements that we have released preview for Jenkins on the system configuration. So you can find information in this blog post. So it announces the feature preview availability. And during the hardfest, there was a lot of user experience testing bug fixes and there is still a lot of follow ups. But the feature looks pretty good. And hopefully we will be able to release it as G in the next LCS cycle. So it's September as ETA. So thanks to everyone who contributed to this story. There was a lot of progress there. The second related topic is Jenkins dark theme. So again, we have created a preview, basically from scratch, which offers a new dark theme for Jenkins. And moreover, we defined foundation for better themes, flexibility. So the most of the code isn't this theme itself, but the Jenkins core changes, which are yet to be released in the weekly release, which is getting delayed. We'll talk about that. But the theme itself is really small, it gets bigger, but still it's much smaller than all the existing things. And hopefully we will be able to get it again to G maybe within a few months. So other hardfest achievements for code include we had a good progress with configurations, tables to disk migration testing. We had a lot of testers who reported the issues. And in addition to that, we had improvements in different stories. For example, new script approval, user interface and script security plugin, which is currently pending review, same in folder authorization strategy that is new user interface created by contributors. And there will be a lot of small stories here and there. Example, better credentials, navigation, some improvements in plugin management, UI, et cetera, et cetera. But we will be posting a blog about that soon. And if you're interested, you can find our major stories here, we published all materials from the hardfest already. And you can watch the recording or watch the slide deck in PDF. Also for documentation, maybe, Mark, you would like to quickly summarize that. Yeah, so we had 40 plus pages contributed, a bunch of wiki migration changes that were made, wonderful outcome from those wiki migration changes. Plugins migrated from using wiki-based docs to documentation as code, good step. This was also our first experience with using GitHub issues instead of using our own Jira site. And GitHub issues have been a smashing success. It's been absolutely wonderful working with them. The Doctor Solutions page has been updated and we've had really good story overall with documentation improvements, still a number of things to review, still lots of reviews needed and more pages that need to be considered and planned for. Yeah, but we will get there. And thanks to Mark for driving this effort because we were reviewing statistics a while ago. In May, we received something like 120 pull requests to Jenkins Ion and it's three times bigger than average for so. So yeah, thanks a lot to Mark and the team for handling that. Okay, we also had some highlights regarding spread awards. So we had a number of knowledge transfer sessions which also recorded and published. There were a lot of nice tweets by HackFest participants and we'll keep doing so. Same for Jenkins, it's the way we received a number of stories. And also we launched Jenkins comics thanks to CommentsTrip and the contributors at Voxx and Electricity who helped with initial reviews. So yeah, we got pretty good results from the HackFest. We still need to publish a blog post et cetera about that. So we started working on that. But yeah, I think it was a great event and it helped us to drive the Jenkins roadmap in the critical stories we have already identified. Okay, any comments or questions? I guess it's only Alex on the call who didn't participate. I'd like to give a huge shout out to everybody. Sorry, Alex, go ahead. I was just gonna say, now I feel bad. No, wow, just call him out, oh, geez. No, we will organize another HackFest, especially for Alex soon, let's see. Yeah, speaking of the HackFest, we also ran a poll among participants asked what would be the top three things which could improve your user experience. We got a nice feedback there. Longly-dentered pipeline visualization and a few other bits. So we will be processing this feedback and publishing. So definitely there is good opportunities for few other events. So any comments? I guess not. So yeah, maybe I will just spend quite a lot of time. So we don't, the Jenkins configuration, yes, we covered that, a dark theme, we covered that. Yeah, another highlight, actually low light we had is Jenkins Centra Otage yesterday. So why I bring it up there because there are still some consequences we need to figure out. So you can find the summary from Olivier in this list. And yeah, thanks a lot to Olivier, to Team Jackamp, to Marky, to Daniel Beck and other contributors who were troubleshooting that and getting it back to the stable state. So we have the infrastructure mostly restored. Although there are some issues which we will need to figure out. For example, we lost history of Jenkins accounts database for something like three months. So we will need to follow up on that. But in general, the instance is back to normal. So for us, there are some issues because some contributors may have lost access. We will need to restore that. We will need to figure out how to modify them, et cetera, et cetera, but yeah, for the information of the governance board, yeah, this topic is being handled right now. Any comments, questions? Okay, even him, let's move on. So the next one is quick JSOC updates. So we have started the coding phase. Right now, there is nothing really surprising, corn expected. So all projects are ready to coding. All projects have enough information. Students got knowledge transfers. They go to the required permissions and they're ready to iterate. Again, we have six projects which are focused on Jenkins, one project which is focused on Jenkins X. And we have already had a number of prototypes being presented. So for example, GitHub checks API and custom Jenkins distribution build service. They have been presented during the UI UX hard test. Again, you can find the recordings here. So record sessions, you can just find them on the website or on the Jenkins Online Meetup. We also have prototypes for a few other projects. So it's going pretty well. And let's see what the first recording phase brings. So as always, in the end of June, we will have demos. Hopefully all projects will present them. Okay, so any other news which we didn't cover? So you didn't mention Google season of docs in the news updates. Maybe that is one worth at least noting that we are an approved project in Google season of docs and we're looking forward to it. We're in this, we are about to enter the phase where the candidates prepare their proposals. And we have from any candidates reaching out in the mailing list or in GitHub chat. So for example, if you go here, you can find that there is a number of applications from the four-point contributors or from newcomers. Some of these contributors have already submitted pull requests as a part of the relation. Some of the users participated in the UI UX hard test. So it's going pretty well. And yeah, let's see what it will be the results. But yeah, I'm pretty confident that you will have maintained this program. And let's see what we could get more. Okay, anything else we have missing from the list? Yeah, one thing that Jenkins LCS release candidate. So maybe we had a slight delay in the back porting, but right now it's here. So if you're interested in a back porting to the next LCS baseline, you can find a pull request right on the Jenkins IO. Sorry, on the Jenkins GitHub repository. So there are two other proposals on the discussion. And if you see anything else missing from the back port and pull request, just comment. So we have switched to the open discussion process for back ports. We've used it many times before. Now we use GitHub, but everybody is welcome to join and make suggestions. So pretty much the same for weekly releases. So Jenkins weekly releases being delayed. Yeah, and taking the status of the infrastructure, it may be delayed until the next weekend. So I'm not 100% sure about that. Maybe you have some information on what would be the term for the weekly. I believe the weekly is in process of execution right now and it's in my hands to pick it up. So we are doing quicker. That's my understanding. I haven't checked through the VPN to see its current status. I just wrote myself a card that reminds me to check for 2.239's progress in the job right now and I'll have to do that after this meeting. Well, thanks a lot for doing that. So unless we hit unexpected issues with infrastructure, everything should be okay. Thanks, Mark. Okay, should we press it to other topics? Yes, yeah. Okay, so I'm bringing back the topic about Windows support policy. So I know that we approved it at the last meeting, though there were some developments during the review. The only notable development except edits, inverting, et cetera, is support for Windows 10. So originally it was suggested to be T1 full support, but yeah, the very legitimate comments from James North that we actually have no testing for that at the moment and that our level one support definition explicitly states that we run automated testing. So after this discussion of Windows 10 was pushed to level 10 and Alex was talking about setting up something for automated testing. Yeah, I have a WEN 10 agent that we can use on Azure. There's not the capability of doing it on AWS because of the licensing issues, but Azure provides a base image that you can build on. So I basically took the template that we had for the Windows 2019 server and in our Packer images repository, and I created a Windows 10 version of that that uses the Windows 10 base image and installs the same utilities, open SSH, et cetera, so that we should be able to use Windows 10 on Azure as an agent. Yep. And Alex, how do you envision referencing that? Then we would explicitly ask for WEN 10 as a label, something like that. Yeah, so the label I put onto it is WEN 10. So that was just the label I put on it now. If we need to, we can change that. And so that it's available. I haven't tested it a bunch because I just, I haven't had the opportunity, but it's something we can test. Great. Yeah, so one potential issue with this approach is acceptance test harness, because yeah, definitely we can run a commonly built unit test, functional tests on Windows 10, but are we willing to run acceptance test harness there and are we willing to set it as a criteria for level one support? We should be able to run everything. I mean, it's just whether Java runs on there, right? I don't think there's anything specific to the server OS in the acceptance test harness. No, there is nothing really specific except duration. So our current situation that basically acceptance test harness has been run by Red Hat as a part of this candidate testing. So if you want to set expectation that we run a full test cycle for LCS release, then we need to figure out how we run it on Windows 10. Okay, that's something I can look into. Yeah. I don't have strong opinion about setting it as a strict requirement. And yeah, I'm also, I also don't have a strong opinion about Windows 10 as level one or level two. Yeah, I mean, I think more commonly people would use Windows 10 as an agent system in my opinion, but who knows, right? Whenever I say things like that, I'm always surprised at what people end up using on where. I don't see much difference to the users in terms of tier one versus tier two. It runs, tier one has automation in it, and that I think I like that it includes ATH, that's nice. I would not object personally if it just stayed as tier two. Delighted that Alex you've invested in creating the Windows 10 checkout infrastructure, that's really great. But given the eight hour execution time right now for acceptance test harness on ci.jankins.io, I'm not sure I want to lobby that we increase putting more things under that. Yeah, I just wanted to make it available in case it was, it was a low effort thing to create it. So I figured I'd make it available and if we want to use it, we can, we don't have to use it, but it's there. I think that adding it to the run list would definitely make sense. So if we have an opportunity at least for functional tests for stable branches, yes, of course, we don't have to make it as a part of any pull request run because I don't actually expect any practical difference for 99% of tests we have. But if you could enable it as a part of LTS check, I'm plus one. Yeah, I like that. I agree with you wholeheartedly that I don't want it being included in pull request evaluation, increasing the load on pull requests. The other is with the licensing concern, it sounds like it's Azure specific. And if we need to host infrastructure agents on AWS more strongly, the Azure specific licensing limitation may be a difficulty to overcome. We could pretty much migrate any of the Windows 2019 or Linux agents to completely be on AWS in terms of the VM based agents. We still have the ACI agents on Azure, but we can eventually hopefully move those over to ECS. And then that would significantly, we could reduce our costs on Azure even more by just running things that can only run on Azure. Which would be one of this thing, right? Good point. Thank you. Yeah, especially if we fix the C2 plugin. So it's on my list for June, but here right now, I'm not exactly happy about stability. And yeah, thanks a lot to Mark for handling all these issues almost on a daily basis. Okay, so I think we agree that we want to use this opportunity and to run it. What do we do about the support policy? Do we want to publish it as tier two or do we want to delete, have tests established and publish it as tier one? I say for Windows 10, is that what you're asking for specifically? Yes. I would say is tier two because we don't have a tested agent right now. It's available, but it's not like fully tested and stuff like that. So if we do decide to use that agent, we could move it to tier one, saying we're running tests on it and things like that. But I think leaving it at tier two is perfectly fine. Agreed. Okay. Yep. Any concerns about that? Tier two and publish because I like having the support policy published. Okay. So is everyone on board here? Okay, then. Okay. So nobody again. Is it against? Okay, then I will just make sure that we request after the meeting. Okay, the next topic. So the next topic is promoting AWS sponsorship post as Jumbotron. So just to provide you context, there was recently a blog post by AWS about why Jenkins still continues to serve developers. So yeah, it includes some statistics about Jenkins rows, et cetera. It also includes information how to actually use Jenkins on AWS, with Kubernetes, with AWS Lambda, S3 and other components and also a reference to Jenkins project running infrastructure in AWS. So I wonder whether you would be interested to take this part highlighted as Jumbotron and reference to this blog post. Yes, plus one for me. Yep, plus one. Yeah, plus one. Okay. I really like the graphs they did where everything is up into the right. Yeah, ideally we need to update, update starts Jenkins.io to do these graphs automatically for new visitor. And there was some research by Manuel Resena about creating a new stats site. So I'm not sure where is this research, but yeah, I think that it would be useful in general. So we agreed publish as Jumbotron, Jenkins project now runs on Diver. Yes, plus one. Yeah, I'll probably forward it to the Jenkins board. Yeah, I'll submit the full request. So there was a question from a lot. Should Jenkins contributors interested in hosting apply for AWS credits? So I think it's slightly unrelated to this particular blog post, but the main answer here would be that if you want to apply, please feel free to apply. The problem that for this, so you can apply on behalf of the project or you can apply individually. So I guess applying individually as Jenkins organization, we already get sponsorship. It was handled in a slightly different way, but we have a confirmed sponsorship by AWS and it's $5,000 per month or 60K per year. So we already have this sponsorship. And yeah, there are some ongoing discussion about how to manage permissions there and the Olivier is working on that, but we've already got sponsorship. If you want to apply for individuals credits, then you can use this form and to ask for one. And Oleg with this, I wasn't aware of this. I'm glad you've shown it. So would this conceivably be something that a documentation person might use to get access to a Kubernetes cluster with using AWS credits to allow them to host their own small cluster? You can answer the question. Yeah, what you just, that example you gave, you are correct, somebody could do that for like for docs for that example. Great, okay. So it's a, because I don't have a Kubernetes cluster trivially available for me personally. And so I'd have to rely on somebody to sponsor that. That's great. Thank you. Okay. So I guess that's it with this question. What does it answer your question? Yes, it answers. Thank you Oleg for clarifying. Basically I wanted to know if individual contributors for Jenkins project, especially for G Google season of docs, should they worry about funding? And should they like take some actions like? Yeah, so specifically for Google season of docs, same for Google season of code, sort of summer of code, we handle that as a work that means. So if you need specific infrastructure to work on your project, please contact Orchard means and they will help you. Well, for Google season of docs, the project starts in September. So before September, if you need a special infrastructure, yeah, it would be good to ask for credits. For example, we had such cases, this spring is some of GSoc projects. If you ask for credits, you're likely to get them for evaluation. If you're working on a bigger project, which needs something as a Jenkins contributor, yes, we can discuss that. And lately we will be talking about funding, which is loosely related to the topic, because if you want to spend money, you need to get money first and we'll talk about that later. Thank you. To also add on to what Oleg said in terms of Google season of docs for Orgadmins, the Orgadmins for this season are Oleg and myself. Yeah. Okay. So let's move on then. Okay, so the next project is about the dedicated projects in continuous delivery foundation. So we have Dan Lawrence on the call. So probably Dan could cover this topic and do some quick introduction. Sure. Thanks for, can everybody hear me? Yes, we can. Yes. Yeah, so thanks for inviting me here today. So I'm a software engineer at Google and I'm also currently the chair of the technical oversight committee for the Continuous Delivery Foundation, the CDF. I recently replaced KK in this role, who was the TOC chair for the first year. As part of the first year, the CDF, we work to establish criteria for projects that are members of the foundation and the initial set of projects were all donated, including Jenkins replaced in the incubating category while we came up with criteria and process for moving things along different stages. So at this point, we're pretty happy with the graduated stage criteria and we're hoping to move the Jenkins project since it's clearly mature and ready to be graduated through this as kind of a test of the process and then we'll start on the rest of the projects. So we've been working with Oleg to kind of find any unclear things in the documentation and I'm sure that it all makes sense for a successful project like Jenkins. So this is what we have so far. Oleg helped us identify some issues here that we think we've all fixed and corrected at this point. Yeah, so if you follow the CDF-TAC menu list, there will be some topics discussed. For example, compliance. So this is what we are already working on in the Jenkins project. You can find some of the references in the menu list. And actually right now Jenkins project was at 80% compliance. We still need to pick some items but this needs to be addressed. And there are also some process issues here, for example, related to governance references or to public list of adopters, which we will need to figure out. But all of them seem to be rather process issues than technical blockers. Hopefully we'll be able to finalize that. Awesome, and I see Tracy's on the call too but the goal here is to just help out the Jenkins project with kind of marketing and other types of resources as we announce this graduation and show what kind of Jenkins is an example of a really well run open source project that we're using as a model for our others. Yeah, thanks, and I think it would be good if we can kind of pencil in a target date for this. Just I think there's a lot of different folks we can get focused on this if we sort of pencil out when it would happen. And I'd be inclined to suggest sort of end of July or early August as when this would happen, knowing what CDF wants to do and knowing that this is within site for Jenkins. So, yeah, for end of July, my main concern would be CI certification. So, we see CI. Yeah. Yeah, on that one, I think the intent is that just is already met here. I think you've, I don't think anybody is really in 100% compliance with CI, so I think the way it's worded is just that you have a badge and I think the 80% compliance is definitely enough for, I don't remember the name, the nomenclature now at this point, but for one of the CI badges. So, I think you're fine there already. Okay, so, yeah, I have a questionable check though. Oh, sure, go ahead. Do we have to go through any type of special security audit? I know the CNCF has like this, but for the incubation and graduation process, they have like special, you have to go through a security audit and publish the findings for that security audit. Yeah, great question. So, we decided not to require a security audit for projects, but we are making them available so and recommending them. So, yeah, if the Jenkins community or anyone's interested in a security audit, then yeah, we can definitely start getting estimates and reaching out to the different security audit firms to figure out how much that would cost and then make sure we fit it into the budget. Yeah, so specifically for CI, for security audit, for me it was one of the reasons why I started the discussion about the current infrastructure initiative because COVID, I'll just, and yeah, I lost the page, I lost the meeting. So, current infrastructure initiative assumes that there are some additional findings available from through Linux Foundation and through CI vendors, which would help with security audit. Because security audit for the Jenkins project, yeah, first of all, it's just expensive due to the project size, et cetera. So, the easiest way to do that is actually to facilitate it through community, through current infrastructure initiative. So, yeah, there are companies funding that and there is a history of some programs like census, et cetera, which we are funded by current infrastructure initiative members. So, if you want to do security audit, it would be definitely useful for the project. Then, yeah, once we get wages, once we officially become a part of the program, we could try to get funding through that. Yeah, I'm sure there's tons of sources for funding. We can reach out to you through the LF, especially in the security scope. I think the, yeah, the first step would be it. Let me correct me if I'm wrong, Tracy, but I think the first step would probably be just for the board to ask the LF to get us some kind of quote for a security audit. And then if it's too much for the CDF budget, we can explore other sources. Yeah, now that sounds right. Yeah, so, for example, for comparison, current infrastructure initiative, yeah, the EDIT security audit for Kubernetes. So, yeah, $157. Yeah, it varies greatly. Yeah, but still just getting into this program, it unlocks potential resources to do these audits. And since Jenkins is definitely used by many companies in this list, I think that we would have chances for getting such funding, but let's see. Yeah, I'm sure we can find the money somewhere. As I was going to say, I think that's the whole, like the point of CDF is it wants the projects that are part of it to succeed and to continuously keep evolving. And I think there's ever increased, like one of the key things at the board level is security and giving the industry confidence for the projects and platforms they use. So, I'm confident to say this, we can figure this out because it's of key importance. Awesome. Awesome. Yeah, and I guess just while I'm also here, I am interested in just hearing any other requests or any other ideas that you all have as the Jenkins board on things that the CDF, TOC can be doing to help other than the security audits. A great one though. I have one last question. And I do thank you for being here Dan, as they see as well as everybody else. In terms of the Jenkins Code of Conduct, do we at some point need to have that, has that been reviewed by the CDF to make sure it's following specific guidelines? And I'm also wondering the want to add on to that. Does it in the CDF or does it make sense for the Jenkins product to have a sort of Code of Conduct committee? I just wanna make sure those are aligned. Sure. Yeah, so I'll just repeat the two questions. Does the CDF need to review the Jenkins Code of Conduct to make sure it makes sense slash has that already happened? And then does it make sense for the Jenkins project to have a Code of Conduct committee? And so for the first one, Oleg raised this, a question about this a couple of weeks ago and we discussed it in the last TOC meeting. But yes, so the CDF does specify that you have to have a Code of Conduct. We have one that we recommend for the CDF, which I'm gonna mess up the exact version numbers here. But as a default, the CDF recommends a version of the contributor covenant, which Jenkins also uses. Jenkins just happens to use a different version of it. And then since the CDF picked our recommended one, there have been a few new versions of the contributor Code of Conduct. So we're falling behind a little bit there too. So there were no concerns raised with the one that Jenkins uses. We are gonna do a little bit of digging and to figure out how frequently things should be updated slash how to keep up with the new versions of this as they come. We're also making sure we're reviewing the changes and making sure they make sense. But yeah, so there are no issues with the Jenkins one as it exists today. Yeah, so yeah, I'm looking for the correct location of Code of Conduct there without opening a mail. So I can just provide versions because I remember that. So Jenkins, you can find Code of Conduct here. This Code of Conduct is a contributor covenant. 1.3. So this version was published around 2015. And when there were discussions about introducing Code of Conduct in Jenkins, this version has been taken as a baseline. CDF uses version 1.4, which is a bit newer. And this version covers some needs which are not covered by the version we use right now. For example, it's more explicit about social media, resources, et cetera. And personally, I think that we should update Jenkins Code of Conduct to a newer version. At the same time, what is new version is an open question because it continues David Foundation uses 1.4. But there is already version 2.0 on the contributor covenant side, which again includes some changes here and there. So from the Jenkins standpoint, I think that having a discussion about updating Code of Conduct would be useful. And it basically brings us to the question by Marky whether you need a Code of Conduct committee. And for this question, my personal opinion that developer may not understand that Jenkins governance meeting is probably enough. But yeah, Marky, it would be better to know what's your opinion about that. Do we need to introduce new entities, et cetera? I think as long as we're transparent in what we're doing, so yes, the developer mailing list would be good. The using this meeting venue to do that would be great. And then for any decisions that are made or something that's forwarded from these two venues to the board and then ultimately onto the CDF TOC would be good. I just would ask that we just somewhere if possible document what we do. So that way it's clear to everybody and everybody's it's transparent. That's my main thing is to be transparent with the Code of Conduct. Yeah, I think an update here probably makes sense exactly which version I think we'll leave up to you on the Jenkins committee. I think, yeah, as spelled out in all of these a Code of Conduct committee does make sense. For the CDF at that level, we just have an email list that goes to a bunch of responsible people. We haven't had to use it yet, thankfully. But yeah, and we do want to make it clear that in escalations or cases where the Jenkins Code of Conduct Committee feels they can't handle something they can reach out to the CDF for more resources. Yeah, right. So it was also discussed at the CDF TOC may be increased. So main difference between CDF Code of Conduct that uses Conduct at CDF foundation or whatever. Jenkins project uses governance board as the escalation stage. And if you could agree, for example, to have a two level escalation, like the first thing Jenkins board then second level is continuous delivery foundation. I think that it would be just the best two walls because Jenkins board members can reach out to all sides, try to mitigate it on the project side, probably get the other contributors involved to mitigate the issue. And if it's not possible, if content census cannot be found, then it can be escalated to the CDF. I'm also plus one for that. I just want to make sure we're somewhere, somehow calling that out. So if somebody wants to do something anonymously to feel safe, they know exactly what steps will be. So nothing comes as a surprise to them. I more just want to make sure we're protecting the community. Yeah, so of course everything should be public. Right now everything is actually, so the current process is fully documented on Jenkins.io slash conduct. So Tyler Croy has defined this project. And again, it was public to discuss, it was discussed at the Jenkins governance meetings and formally approved by the community. So you can find references in the list that goes, yeah. So it was formally adopted on June 1st, just four years ago. But yeah, I guess here we would be using the same process for the public discussion. If there is a consensus at this meeting that we want to create code of conduct, I think that it's a good time to start this discussion. Thank you for taking a question. Yeah, so yeah, I'll probably just start the discussion unless somebody else wants to take this section item. So anything else about this topic? Nothing for me. Thank you, Dan, everyone. Yeah, thank you, Dan. So thanks for having me. Yeah, I guess the next step or force could be, again, to start this discussion in the mailing lists, and basically what we discussed today. Yeah, also discuss these dates, but if you can agree on this here, I think that this date is fully plausible. So somebody would need to start discussion about CDF graduation. So Trace, would you be willing to take this item? Yeah, assign that one to me, please. So should we move on? Okay, let's continue. So yeah, the next topic is about community bridge funding. So I'm just bringing it up again. So there was all discussion, but after that, everybody was busy and it just got stalled for a while. So it was discussed in December and in December, the governance meeting, we agreed that it would be great to do something about our funding because it just make status summary. So we have two ways of the nation which are officially documented. So one is SPI. And for SPI, there was agreement that the SPI governance board meeting one year ago that SPI wouldn't be accepting the nations to the Jenkins project. So the fact that they keep accepting them and I guess it's subject to change once the transition from SPI to CDF is completed for the Jenkins project. But yeah, this way is marked as, let's say, unstable. Another way for documentation is through FF-SDE site. So this way was documented on the original weekend. And the current state with that, Udi Hafner, Jenkins board member is working on that. But the current stated that we have no idea whether this way of donation is still active or not. Udi tried to contact this site, why email, et cetera, he didn't work, he also sent official email through German post. And again, we still have no answer. So this is a safe assumption that even if this way is technically feasible, it's not working. So we probably get rid of that. And it leaves us with basically no ways to donate to the Jenkins project. At the same time, we have a good experience of from community bridge last year, definitely we could use some money for Schwark and other stuff. So there was a proposal to actually go with community bridge. And there is a prototype set up for the project. So you can find it here. It was basically set up for community bridge mentorship, but it's fully operational right now. It has some funding goals, which I come to test once, but it received a few contributions there, but this way isn't documented anywhere. So I started working on a job draft. I submitted it basically right before the meeting what I have. So this job is not nearly complete for being published even in the draft. But the main idea of this job would be that let's publish community bridge funding as experimental process. Let's update the Jenkins ID documentation to suggest as a way of contribution. And let's update metadata for Jenkins core and for infrastructure that it would be pointing to community bridge. So I set up a quick prototype here in my personal repository, but how it will look like. So there is a sponsor button, which is enabled by funding camel. And this fund camel basically contains two entries right now. So it's community bridge Jenkins, which points to community bridge. And another link will be pointing to donation policy. Right now it just points to Jenkins IO website, but once JEP is ready, it will be pointing to JEP. So basically it would document how we spent donations, et cetera. And once this file is in place, everybody would see a sponsor button, which would be pointing right directly to the community bridge and also to the donation policy. So you click here and you get a way to donate, including targeted donations, for example, to documentation or to meetups. And also you would be able to spend periodic donations to do company donations, et cetera, et cetera, powered by community bridge. And the community bridge is basically Linux foundation. So it's a part of the services provided by the Linux foundation and so several project numbers. So this is the summary of what I'm working on. But yeah, it's not ready for voting right now, but my intention is to just enable it in a few repositories as a prototype. And I would be happy to get feedback. So Oleg, it looked like you were preparing the prototype that could be potentially, eventually applied organization-wide for the entire Jenkins CI organization on GitHub. Did I understand that correctly? Well, this is a bit tricky. So for example, there is no problem with applying it to Jenkins infrastructure because the entire infrastructure is basically controlled by the Jenkins project. For Jenkins CI organization, to be honest, I would rather not enable it globally because we have plugins, et cetera, being developed by different organizations, different contributors. And I'm not sure that everybody would be 100% open to have a Jenkins donation button enforced on them. So it's totally possible to override it by adding your own funding, but even the fact that we force it right by default may be not appreciated. So right now, I'm not proposing that I suggest to do it for Jenkins core, maybe for other components within the Jenkins ecosystem, but not for the entire Jenkins CI organization. Got it. And you said we could conceivably do it for Jenkins Infra, but then others would need to opt in. So if the EC2 plugin, as it was an example on the screen earlier, if they said, oh, we would like help, they might be able to opt in. Basically, if you're a plugin maintainer, you have multiple ways. Firstly, you can just join Jenkins funding. And then you can ask for donations for some money. Basically, you can ask it right now. So as a maintainer of EC2 plugin, you can see that it has a part of the Jenkins ecosystem. So you can reach out to the developer if you want to get some expenses. So you can participate in JSOC, JSOC, Outreach. You can propose projects there. So you have access to Jenkins funding right now. But for example, if you want to stop your own funding due to whatever reason, you totally can do that. Funding. Yeah, so basically there is a sponsor button. There are multiple ways. And I wouldn't really like to enforce something on the plugin maintainers. I would rather keep away for users and maintainers to define their own funding ways if they want to do that. Okay, so lots of flexibility. Great. Thank you very much for the overview. Yeah, so it's a subject for the discussion, but I would rather prefer to keep it to opt-in. So Marki, what do you think about that? What would be your preference as a maintainer? So yeah, you can see that. I liked the way you described it where people can opt into it. I think that's probably the best way to do it. Yeah, so for example, we can see that there are already funds depending on funding here. So for example, we can take a look at localization and change these plugins. It's somewhere. Okay, but it's basically defined for the Chinese community. Why not? Pretty much the same, for example, for, let's say, a monitoring plugin. I guess that, yeah, right now basically it's a GitHub sponsors for plugin maintainers. Again, why not? So you can sponsor Evernote. Yeah, well, whatever works. Yeah, I'm a plus one. Okay, so I'll just move it. So no enforcement. Yeah, we'll get it documented in the JEP. Yeah. So for Jenkins and for one of the issues with community bridge that right now there is no destination for infrastructure specifically. We had a meeting with community bridge last autumn when we were discussing community bridge mentorship, funding, et cetera. And they said that there is a request for enhancements for that, which would be delivered soon. So definitely soon hasn't come yet, but eventually it would be there. And once it's there, of course, we should enable it. But even now, yeah, what I put in the JEP draft, it will be development infrastructure. So for example, development, we can use it for funding infrastructure needs if needed. Well, it's pretty much the same for documentation because Jenkins has to be hosted somewhere. If you want to ship documentation from fastly, if you go beyond the sponsorship by fastly again, we could use this money to pay the difference and so on. So even without infrastructure category, we can spend money on infrastructure. Moreover, the current community bridge documentation basically says that whatever you submit money to, it's still a decision of the organization how they spend this money. So we are not forced to use that as is. And right now there is an opportunity to actually submit money without specific dedication so that everybody can use them. But yeah, let's see. And we have awesome $6 for documentation now. Which is $6 more than we've had before. So that's, see that as a bright. Yeah, right. So well, this website isn't promoted anywhere. And I would say that unless you search for Jenkins funding directly on this website. So right now there is a search button. It wasn't in case three months ago. But yeah, even with this search button, you have to search for Jenkins specifically to find that. So it's not exactly visible until we get it added to GitHub sponsors or whatever. But yeah, you can see that some organizations actually raise money quite efficiently. So there are different use cases. So for example, a key card, et cetera, the crowd fund that manager, there are two common use cases being promoted by this foundation. Some other organizations rather targeted sponsors. So for example, if you go to open mainframe, you can see that there is one contributor, which is Linux foundation, but whatever works. So yeah, I think that in our case, we can do a combined thing. So we can use some money. For example, you can see that right now we have $3,000 transfer. Basically, we're just putting money from one pocket to another one to find a community bridge. But technically, organizations, et cetera, can also do big targeted donations. So I think it's a lot. Okay. So I'm not asking for approval from governance meeting to approve it now because it's not ready for approval. But yeah, we'll try to get it over the line maybe next weekend so that we can finally publish it. Because yeah, we definitely can use some money. And you're intending to use the Jet process, which feels like a very good organized way to approach the governance. So maybe we have Japs. So any other comments? None for me. So maybe one topic which was mentioning that basically Jenkins mentorship page is also public. Again, they have changed the website recently. So some bits broke. But in principle, Jenkins mentorship page is there. So if anybody wants to run mentorship program, we have some money now, SPI accounts, not that much for the record. But if you want to run unpaid mentorship programs, we definitely can do that. For paid mentorship programs, we can shake some trees, et cetera. And again, we can probably do that. So this question has already got brought up. For example, last week at the UX Hackfest, so what do we do with this documentation? Because JSoT is just one project right now. So this is probably our way to do that. Right now applications are closed, but technically we could try to run another session in September, wearing that we have enough mentors, which is always a problem. And yeah, three mentors are on the call. Okay, so that's it from me for today. There was a topic about posting plugins with proprietary libraries. I'm not sure whether we want to discuss it now since we are already over time, or should we postpone it till the next meeting? I say punt to the next meeting. Plus one. Next meeting is fine. I assume that that will continue discussion in the dev thread that was in. Yeah, but this threat is not the detective. So the next meeting is June 17th. I guess there's nothing which needs a change in this date. So if anybody has a band-wife about this topic, you have to take a look at this. That might increase discussion, but again I don't anticipate any specifications from the board right now because our governance policies speak explicit about what we host and what we don't. So let's see whether we can resolve this topic using various technical solutions which are available. And if not, yeah, then we can discuss with the governance meeting. Okay. Excellent. Yeah, thanks, Sol. Sort of for going over time. Okay. I will see you all online. Have a good evening. Have a good day. Have a good day. See you soon. Bye.