 Hello. Welcome to the Jenkins Governance Meeting. Today is June 17th and we have several topics in our agenda. So, we will start from news and updates in the project. Then we will talk about updating the code of contact. And then we will talk about approving the community of rich funding page for law. It's a flow up to the previous discussions we had a couple of weeks ago. Then we will talk about forcing against these proprietary libraries. All of these topics are relatively short. So, the intent is to spend less than 30 minutes on all of them. And after that, we will have a discussion about terminology updates and I suggest that we spend all the remaining time on that topic. Does it look good to everyone? Okay. So, let's start. Yeah, if you follow the Jenkins Manning List, you might have heard that we had an issue with all that database. There is a thread in the developer Manning List which provides all the details. A long story short, there was an issue with Kubernetes cluster. While fixing this issue, it was related to the routing of services. Basically, you had to rebuild the cluster from scratch. And after that, we discovered that some services lost the data and most importantly, the user database. So, we lost three months of history, including new accounts, et cetera, et cetera. We were able to recover it using caches in Agira, in Repository Permission Update, and in Artifactory. So, right now, all the accounts are reset and they can be used. So, on June 19th, we also had uncoordinated the disclosure of the security risk. So, we knew about that for a while and we were planning for the fees. But taking the disclosure, we had two block uploads to Jenkins Artifactory and basically uploads were blocked from June 9th to June 15th. So, we re-enabled them on Monday. It caused some impact on plugin maintenance, but yeah, sorry, for any inconvenience, now everything should be restored. So, for plugin maintenance, we communicated the updates and it should be somewhere in this thread. So, it's here. So, this story at least for plugin maintenance is over. Definitely, we have a lot to learn. We started discussions about using another identity management service, which it would be a third party management service so that we wouldn't need to host that. And we will hold the public with respect for all the issues and probably next week once all the events are handled because we still have some follow-ups in the infrastructure team to finalize. I've already started a Google doc with retrospective and I believe that all security team members, almost all infrastructure team members and the Jenkins board have access to that. If somebody else wants to get access to their retrospective document, please let me know. Okay, any questions, comments about the story? So, yeah, I would like to say thanks to Olivier, to Tim Jerkham, to Daniel Beck and to Mark and to all other contributors who were working on restoring the services because it required a lot of background work to just get them running again and then to clean up all these issues. Okay, next news. Now, good ones. So, this is related to AWS sponsorship. So, right now, our infrastructure largely runs on Asia and we get sponsorship by continuous delivery foundation. This sponsorship covers staging and a lot of other services we run and the amount is around 10K per month. And it was a bit higher during the previous months. But we were working on reducing the cost. It was mostly a Mark, Tim, Alex and Olivier working on that. But we don't only use Asia, we use other services. And one of the concerns for us was AWS because AWS was historically sponsored by CloudBees. And we were working on moving it to continuous delivery foundation. And as a part of that, we agreed to have sponsorship by AWS. So, for this year, we've got a $60,000 donation from AWS to keep running AWS. And we run Jenkins agents and CI Jenkins agents on AWS as well as a number of other services. So, it kind of works and it definitely helps us to reduce the cost of sponsorship because, yeah, when we started optimizing for the cost for Asia, it's something like almost $20,000 per month, which was above our target. So, how usage of AWS etc helped us a lot to optimize. At the same time, we experienced some stability issues for agents and it's in our list to handle. Anyway, thanks a lot to Amazon for providing the sponsorship because it's a huge help. One of the things I'm looking at to reduce the cost on AWS even is they have something similar to the ACI that Azure has. So, it's the ECS Fargate. So, I'm looking at setting up agents with the ECS as well. That should be a lot cheaper even than the VM instances. Yeah, definitely. And we have a lot of tasks which could be automated. Maybe we could even use AWS Lambda for some of them. Probably not for CI builds, but we have a lot of automation which could be done on Lambda as well. But, yeah, Fargate would definitely help us. Okay, and speaking of that, there was a blog post by AWS. Just a second. I'm trying to find the link. Yeah. Did we exclude? I don't know if we linked to the original blog post from AWS and I apologize that probably should have because they did a brilliant post on their on AWS's blogs open source blog about Jenkins as an ongoing viable and Yeah, there it is. Yeah. Yeah. So, yeah, this is my interesting create. If you're interested take a look. Any questions, comments. No. Okay, then let's move on to the common agenda. So, one of the topics we have is updating Jenkins code of conduct. There's a minute list about that. Yeah. Originally I started the more proposal to update version 1.4. Right now Jenkins has a code of conduct. And they found on our website. This kind of conduct is based on contributed common and version 1.3. So this is the version which was available in late 2015, when we had a discussion about code of conduct. This is the version which was updated and since that we have never updated it. The same time, there are two versions which are currently available. So one is version 1.4, which was became available in 2017 or so it provides a lot of changes, especially covering social media providing examples of advice behavior, not on the prohibited one like ours, but also some best practices and it keeps evolving. The version 2.0, it's also linked from the mailing list, it goes even further because firstly it stops focusing on project instead of it starts focusing on the community. So maybe you have heard about a project called community covenant. So basically contributor covenant to the zero includes community covenant right inside. And there is a lot of enhancements in wording in scope, etc. So why I proposed updating to 1.4 originally, there were two issues. First of the issues that we are going to show what the foundation would be fine with us going to the zero, because we also have an ongoing discussion about the application, one of their separate it is adopting code of conduct. And this is the foundation now uses version 1.4. And as you may imagine version 2.0 is not exactly compatible. So we need the confirmation where the CDF would be fine with us taking that. And yeah, they're fine. The obstacle was that version 2.0 basically had no change lock. So it was discussed and I made the best effort attempt to write a change lock. Thanks a lot to Jeff for feedback because a majority of this change lock is based on the feedback in our developer mailing list and also communications and the contributor covenant. Right now you can see that there is ongoing discussion about wording, etc. But at least there is a change lock which we can use for the news. So my question to both and to other contributors is what do we want to do? Do we want to update and if so which version? Based on the diff that Jeff kind of went over, I think the 2.0 version myself is the one that I would recommend. I liked the things that Jeff noted in things that he liked. Yeah, and it is my preference I will say I went through it and reviewed them closely. Like you see there and I think the 2.0 would be better. Did you see any things in your review of it that you thought would be a risk that CDF might reject contributor covenant 2.0? Well, we already have information from CDF that they want. Oh, okay. All right. Thank you to technical oversight committee on Monday. Once we have had this full request, good confirmation. I will say that to the agenda of talk meeting to formally approve that talk meeting yesterday was cancelled. But yeah, I believe that the initial feedback is enough for us to continue with adoption if you want. After reading Jeff's comments, which were very, very awesome. So thank you very much for that Jeff and going over the 2.0 contributor covenant I'm voting for the 2.0. I don't see that we really have any blockers for going to the 2.0. My colleague said, you know, the foundation is fine with it. The maintainer has reached out has responded about putting together the change log. I think we can get something complete in there. So yeah, I don't see that we have a necessary blocker or I don't see anything in it that makes me concerned. Anybody else does or anything, you know, raise it. Yeah, personally, I also prefer to do zero taking the information we have at the moment. Mark. 2.0 is fine from. Yeah, 2.0. That sounds great. So what would be our next steps? Just so I can go ahead and submit a political request with update because it's not exactly trivial to update. For example, we have our own enforcement. And we have enforcement guidelines in version 2.0. I think we should check alignment. Also, there is CDF code of conduct, and I think that we should have a two level escalation process. So first escalation as is to the governance board. And second level would be CDF. Because why it's important we may have some cross project issues. Or if somebody disagrees on the project level of a way to mitigate it on a high level with also make sense. So, just, I don't think that we should vote on adoption right now. So you can agree that we go with this version. We can take an action item to submit a pull request, which does the update, then we can vote for final question the next meeting. And after that a former adopted. So, and that pull request because it's going into the governance section will be tagged for government governance and therefore it won't, it won't immediately be merged, even if people list approval, or is that one where we should be holding off approval until it comes to the governance board we review it without giving an approval. Yeah lessons learned so I will put on hold label. Okay, you will. Yep. So, how it works right now. Just for those who are interested we have co donors. And there is a section which is explicitly owned by Jenkins board. So governance documents project conduct the need press such things. And the governance board is requested as a reviewer for this document. Obviously it doesn't block copy editors from merging the things, but we have maintainer guide at the moment wasn't introduced one or two months ago, and it specifically covers topic about structure and ownership. And in order to prevent collisions just in case. So for example I have a public request for meeting the donate page is a subject for this agenda but when I created it I also put it on hold. So, yeah, it prevents unintentional merge. And if something happens we always have an option to revert that. Great. Thank you just as one of the people who's made that mistake in the past of merging to aggressively thank you. That's great. Oh, first study. So, yeah, yeah, we've all done it. Yeah, so my action item is to propose a public request to the code of conduct. Now, Oleg is that something you want to delegate to someone else, you know, it's, you've got you've got uniquely skills to handle that so I've not not questioning the skills but your capacity I hesitate to overload you with everything is that's Well, you somebody else wants to take that I'm perfectly fine. I'm not to such a strong word. I'm not going to offer that I want to take that it feels like a place that's got lots of terminology and will be very challenging. Oh, yeah, that's for me that I get paid to do this tedious and routine work. So I do not gamble. Okay, I will also add that given the. The deadline for what we're doing here and that's for the graduation process. So this is something that I'd like I would love to take it but I really think this is something you should drive home or like, that's not me voting for you to take work. I don't mean it that way it's more critical to review that because yeah. So that I can help you with. Okay. So they will be to level escalation enforcement alignment. I'll fix all the type of Slater. Okay, should we move on any other comments about that. Thanks all. Okay, Jeff 15. So I did a brief demo for the funding process of the previous governance meeting. But at that time, it wasn't ready because we didn't have a job, which will be merged and integrated and we didn't have a purchase ready to go. Everything is ready. So I would like to ask for approval to proceed this publishing the reference implementation. For community bridge funding, what it implies, we replace the donate page. So for example, here, yeah, there is some working changes basically reflects Japan and how we actually spend money. So we say that we use the money on the maintenance structure. It's not exactly correct taking out the history of spending like outreach and the work on other things. So there is extended working from the job. More importantly, yeah, there is the nation through community bridges, the primary way. Also the nation through continuous delivery foundation as a second way for organizations which want to make big donations. And we remove SPI donation and we remove FFISD. So these are two ways which currently linked, but the SPI, there is agreement that they won't be accepting donations. Though they still in fact do, but I think it's time to remove that. And for this vendor, I believe we still don't have response whether they accept donations or not. Because Uli was investigating this topic. So I'm not sure what's the status there. The status for the German thing, SPI? I wrote them in a second mail and nobody's responding. So I doubt that there is someone still there. What I wanted to do, I haven't found the time yet is to write a formal letter using some harder words to see if still someone there. But I doubt that we get something back from it. I think they are just corrupt. I don't know what's really going on. They don't answer mails. The website has been updated, I think, two years ago. So it's not existing anymore. Interesting this website is on and we can access the details of the savings. I think two years ago it's working, but actually I don't think they are really responsive anymore. So I think removing it entirely totally makes sense. At the same time, it still makes sense to contact them because maybe we have some cash there or not. Yeah, we have. If there is someone there, we hopefully get it, but I don't know. Yeah, so who knows. Anyway, I'll try. So yeah, this is the first part of what I would like to approve. It was already approved text-wise. The second part is actually rolling out the funding metadata so that in the repositories, we'll just open Jinxfeldrunner. I used one of my repository projects, a maintain. I started really from my repositories, but now Jinxfeldrunner. So basically they will be a button which points to community bridge funding and also references to widen it. Right now it's obsolete, but once the page is updated, it will be a new page with all details, etc. And the proposal is to enable it widely for the Jenkins infrastructure organization by using GitHub metadata. So enabling it for all repositories. And enabling it only for a few repositories within Jenkins. For example, for Jenkins core and for a few other plugins. Because here, I'm not sure it would be appropriate to enforce it for plugins. So the decision to not put it for all plugins is because an individual plugin developer may choose a different sponsor path. Is that the notion there? Can you explain it further? Yes, exactly. It's not a problem. So they could have it right in the default and put their own ones, but the problem that we would force the default right now on everyone. I'm not sure whether it makes sense at the moment. So we can discuss it later, but I would try, at least for the preview stage, I would prefer not to force that. Yeah, because yeah, we have some plugins we shall loosely connected to the Jenkins community, even though they're forced on Jenkins CI. So yeah, just force some funding. Yeah, I wouldn't do that right now. So question to everyone. So would you be ready to vote for or against that or doing more information to make a decision? I'm ready. Okay. Plus one for me. For me too. For me, for me. Sorry. Plus one for me as well. Okay. I don't have any comment on it. Anyone else? I just joined. So I'm not sure. I'm staying, I guess. Okay. Okay. That's fine. Okay. So this is a proof plan. Well, there was a case we will throw it back because right now you don't have funding quay at all. Right. Okay, then we'll claim it approved. Yeah. So should we finish with hosting plugins? I don't think it's a long topic. Okay, so there was a discussion about one of plugins which was blocked from distribution. It was blocked from distribution because there was a security report about this plugin including proprietary code. So basically, even if the plugin itself was open source, I believe MIT license, it was pointing to alternate repository and pulling private library from there. Basically, it was distributed with this private library. At the same time, we got clarification that the private source code wasn't enabled by default, you would still need to click some buttons to get it running. But formally our governance policy says that we don't host components with proprietary code. So this is what's documented right now, and I wonder whether you want to reconsider that for dependencies. I would say no, I would say we keep the current process there are examples already available on how to do something like this. So I think we should maintain the current, the current process or current rule. I'm also a negative one on this. I vote with Alex that we should not change what we're currently doing. Likewise. For me, it seems like it seems like if we were to say yes to this the complications would be significant in identifying the processes which we would allow and not allow. Yeah, I think it opens a bag of worms. And, and I think since we already have a solution with examples, I don't see any reason to go back and change that. I agree with both of you. Yeah, so there would be an interesting and important flow about improving our scanning tools. Because yeah, right now we do not verify what we publish, even though Artifactory offers some features. Also, you could update our parent homes for maybe a simple cradle to do some scaling. So that we could identify such libraries. Yeah, right now, our tools are really limited. We run maybe license plugin or whatever it theoretically should collect dependencies, but in practice, it doesn't scan the result in HPI file. So depending on how you write your maybe definition, you may bypass the scanner. I am, I'm fine with kicking this down the road. And the reason that I say that is because there will be a feature that will be released from GitHub. It's currently in beta right now that will give us the ability to scan code. And again, there's also the Artifactory thing we could turn on, but I know GitHub will be allowing a feature shortly. Well, I believe that is already good connection for that. They're going to add something even more granular to that. Okay, so any other comments on this topic before we move on. Okay, so the next topic terminology updates. So first of all, thanks to everyone provided feedback in this thread. It became a bit long. Thanks a lot to Alex for starting with. So basically it includes two major topics. One is about changing the terminology for Jenkins Masters and another one changing the terminology for white list and black list. There are a few options suggested, but in the discussion, there are many other options suggested. I will do a quick summary of what we currently have on the table. And yeah, after that, we can press it with the discussion. So for Masters, originally we started from choosing a single term. So there were a number of options suggested. I processed the entire menu please and put it in the Google Doc. If I missed something, please just suggest a change this Google Doc should be open for comments. So if you see something missing, just suggest, but you can see that there is a huge number of options already suggested. So the front runners are controller and server. Some other options also got a decent amount of votes and yeah, so there is a proposal switch head on the one road. So this was one option. The second option we discussed is actually splitting the term. So instead of just using a single term, instead of Jenkins Masters, splitting it by use case. So for example, in the documentation when you say, please go to the Jenkins Master UI, you can just say go to the Jenkins Web Interface. Another way I'm splitting Jenkins's node, for example, Jenkins's network route controller was proposed and so on. So basically splitting this term and preceding in such way, which might be a good investment in the future. For example, if you start breaking down Jenkins to microservices or just to services. For example, we already had a prototype of multi tenant Jenkins, and it might be useful architecture investment for the future. So this is the second option. And yeah, when I suggested to the governor's meeting, basically, it didn't seem that we have a consensus to vote on. And I still don't think that we have a consensus, but we could discuss the terminology and maybe start building these consensus. Yeah, some of the in the main piece. Yeah, maybe it'd be good to have a period of time when we're saying we're accepting suggestions, and then we take those suggestions and do like a Google form and get a consensus that way. I agree there's not a consensus right now for the replacement of that term. We could consider a condorsed style voting scheme right a ranked voting scheme. This might be an interesting experiment on the topic. I'm not sure we'll ever get consensus, but but it's an alternative to let people rank their choices, and then use the rankings. I think that has a lot of potential to do a ranked voting sort of a thing. Can we run a public voting there. So I believe for this option is supported because what I did. Yeah, what I don't want to do is to go through and if I'm talking to users, etc. Yeah, we had it for governance and officer elections. I'm not sure whether you want to repeat it again. Yeah, I agree would need to be public. And still, I would take the voting the result of the condorsed voting as only as only one voice the governance board I think still has the definitive choice. I don't if it were spammed if it were overloaded by people who were being malicious, the governance board could still just ignore the public vote declare that they were ignoring it. Yeah, I think, I think there's a less likely the case that there'll be bad actors, if, if there are only terms on there that are ones we would accept. Yeah, and no right ends. I think if we have only the terms that we would be willing to accept. Then I think that significantly reduces or eliminates the possibility that bad actors could come in and and cause a problem with the voting. Yeah, and again, a concord net is basically is not an open system you cannot propose your vote you can choose one off. And for example, we could select top 10 terms. And put this on the ballot. I like the approach that people are talking about of doing it kind of as an experiment and as a as an input without necessarily saying that's what we're going to go with. Yeah, one topic which is discussion is whether you want. Yeah, so thanks Alex for confirmation. So there is a chart. Yeah, maybe. So one thing which needs discussion is whether we keep don't change on the ballot. Well, it's technically legitimate option. I actually would not leave, I would not put do not change on the ballot I don't think it's, I don't think it's worthy the energy to the organization so I propose to not include do not change on the ballot. Especially since the second battle. Yeah, especially since a historical connotation of master and slave that's what it used to be right so it's not like it was a master carpenter. Right, that was not the, the meaning of the term it was master slaves so I don't think we can leave it as a do not change. From, at least my proposal for the governance board is the governance board selects that not changing is not a choice. I agree with that. We can vote here. Yeah, so, well I'm pretty sure that. Yeah, I don't have so strong opinion here but I'm ready to follow the vote. Yeah, so for me I'm plus one to not change. Same. Same. Same. So, let's mark the polls. Yeah. What's your preference? Yeah, it's good. Well, if you want to abstain it's also fine. No, it's good. Okay. Personally, I also prefer to do the change because there is strong user feedback that we should change. And practically I see no reason not to change at the moment so I'm also against. Actually, it makes the things simple though. We still have a question what we exactly put on the ballot because you have so you also have these options getting the term tomorrow. I don't think that it completely prevents the need to have a single term. For used to be master, but maybe we still can start replacing a lot of terms in the documentation so that you don't train the different on this single term. What was the opinions about that. So, I to be sure that I'm understanding I think what you're asking is, do we like the concept of splitting the term and I like it very much. But I think even with that we still need something that designates the terminology for the the old term, the old representations. Did did I miss a misinterpret your question or like. Yeah, so let's assume. Okay, you select what's leaving there. Okay, we say that now we call it Jenkins controller. And for example, we have a guy then please go to the Jenkins master web UI, and it's not an abstract use case. It's what we have some of the documentation. Will you put Jenkins controller web interface or will you just say Jenkins for the interface. Okay, good and and I have a strong preference there I would say we just say Jenkins web interface because it makes that the phrasing simpler and easier to understand. But now the question, are you asking, is that an item we should be taking to a vote for me I think this one is a is an assumed yes we like the concept of splitting the term and attempt to get consensus in the, in the online forums even without a voting system. Yeah. Okay, so Jenkins web interface is probably the most straightforward one of the, of the use cases. Agreed. When you say Jenkins as network root, what, what are you, what is the connotation or the. Basically, he reflect master but master in terms of network topology. So we have a central note or whatever it's called to which you connect. For example, agent connects to it, interact with that same example, other components like monitoring systems CLA etc. inside this system finally connect to this central point, which is represented by Jenkins. I didn't want to call it note, because in Jenkins note is a different term. It's basically executor or whatever. So Jenkins as a manager. It manages three sources is that we're maybe. So I read them and network topology. Yeah, but this is not complete. There might be other means. So for example, in your case, what do you mention. I said manager. And that was just, that was just the, like the idea of something that the other nodes connect to and it manages those nodes. And for example, you also cannot call Jenkins as a storage, because it also acts as a storage for the system, especially now until we have a little storage in place, and you can continue. I'm not sure whether we are ready to do a deep dive into that now, but I think that maybe we should start working on that and updating our glossary right now. Yeah, you did some page updates in the documentation. So you have terms and definitions now, and here are terms which are officially embraced. So obviously master is going to go from that. But yeah, maybe we could start introducing terms based on use case, for example, update center. It's a standalone component. We will need to update it. I think I like that idea a lot that we consider adding to the glossary these use cases and use the use the glossary edition as the point of conversation about those use cases. We may not be ready to merge the pull request but it's a great conversation. Yep. I agree with that as well but I do also think we should change to the single wording as our main focus of warning. I agree with that we will still need a single wording. For example, what's currently written in our docker image which I have no idea. I guess it's successfully avoided mentioning the master term on the, actually, yeah. There are a few references but basically at least not in the top of the documentation. But in the principle, we need a single term to define some items. So here Jenkins server probably makes sense. So just to note the discussion. Yeah, so recommend Jenkins for interface. We still need a single term. Okay, so let's go ahead and vote on these cases updating the glossary. Is it correct? Yes. Yes, that's correct. Okay. So anything else we can do about this topic today. I guess here we have action plan. One question is about timing. So, for example, Concordnet, it can, oh, so it saves, right, not Concordnet. So it can be set up quite quickly. But I wonder whether we can prepare for that, let's say in two weeks or do we need more time and who would be driving this vote. Would you like me to take that on as a, I'm not sure I can make it fit in two weeks but a status report in two weeks seems reasonable. And I'm interested enough in the topic to, I'll probably enlist Jeff's for support and Alex for some support, but that'd be one I'd be interested in. And I can help you in any way possible. So, oh, like just to be sure I understand the scope here it is that really we want to collect the, collect the ideas and bring a set of possible ideas to the governance board that would then then after the governance board approves yes these are these are viable terms. We then post that condorsed style or CVS CVS style vote. Whatever. So, Alex has started this discussion. So, Alex, so would you like to keep driving a bit. I mean the four terms and listing. Yeah, that's fine. I can do that. Okay. Yeah, and for example, we can then prepare the list etc. to Alex. The next governance support meeting we select at least 10 options or whatever. And in parallel, for example, Mark can work on the technical implementation. Does it make sense. That sounds good. Okay, so I will meet Alex. So, I will make you an owner of this document then. Okay. So, change the term. Let's do the shortlist selection. Mark technical implementation right. Right. Yeah, technical implementation of the voting. Yep. You also need to think about how we communicate that. Because yeah, we can just do, let's say, look post with the link in as one way. Or what if you want to have a big outreach. Yeah, so my, my initial proposal is the more narrow one. Already you've described. I don't know if it's dev list, user list, Twitter, LinkedIn. Those are, are the high traffic areas anyway, but, but it's a valid question. Where else is there somewhere else that we should go. The list user mailing list. Right. Oh, get our channels. Should probably be in there. Yeah, we can also post it in RC. I just don't know whether you will get us much more traffic. Right. We could probably jump out on for this topic. Let's say if you want to facilitate both, why not. I agree. I think the jumbo trend idea is a really good one. Yeah. Yeah. I don't know why. Maybe it's about, by the way. Okay. So does anyone want to take care of that? I can take care of that. So we're just basically going to start reaching out. We'll use the same format to go to all of these venues. Actually, as far as LinkedIn is concerned, I don't have access to that. If you prepare the text, et cetera, I will get it posted for you. Yeah. I thought, like, I thought here, what you were looking for was more of a plan than the actual. Yeah, here's what we should, here's the words we should say and et cetera. Then the specific implementation depends on. The channel and the person. As far as the words that we should say, we're talking about the voting, right? Is this what they will get in the, the actual. Okay. So basically cool question. Yep. I'll, I'll take care of that. I'll take care of that wording. I can have that done by the end of the week. I'll just create a Google doc and I'll share it with. Pretty much everybody that is on here. That makes sense. If you need help with what we open graph images or whatever, let me know. But you know how I create open graph images. So. Okay. I won't say how I do it on the record. Yep. I got that action. Okay. Yeah. I'll just create a Google doc and I'll share it with pretty much everybody that is on here. That makes sense. If you need to help with. What we open graph images or whatever, let me know. Okay. So. Anything else on this topic? I'm glad we're moving forward. Yeah. Me too. And yeah, it's good that we actually started that several months ago. I mean, because, you know, when other things started, we at least had something to say. Including examples of action. And it really helps right now because I'm not sure how many mentions you see in Twitter and other channels. But yeah, there is quite a lot. So. And yeah, for us, it's helpful that we actually work on that. And we started working on that long ago. Okay. And yeah, it's now roadmap somewhere just. Oh, I moved to user experience. Right. So I did some updates in the roadmap to focus more on these cases. So now all topics. They go to user experience. Agent, document, and creation, et cetera. They here. Okay. Any other comments? I just want to go again. It's really good that the Jenkins community and board and everybody's doing something on this. And we just need to make sure not to. Drop it. Not just let it sit. But it sounds like we're headed in the right direction to actually do stuff and. And be able to explain it. Yeah. There is still a lot of technical things to do. But yeah, I think that just doing the documentation cleanup, et cetera, is a great first step for us because we still have some items there. And after that, really, we can think about API and other things. So it's going to be quite challenging. But I think that we should move further as well. Yeah. If we can focus on the more user facing stuff. Some of our first stuff, some of that will be easier to deal with. That's, that's wins and progress. And we can go with that. We've already gone back through all archived blog posts and removed terminology this past weekend. So that was, that was already done. And I'd like to thank everybody in the community for, for stepping up to do this. It's a is what it is. I wish we didn't have to do this more, not the wording, but I wish the wording never existed. So I just want to thank everybody. Yeah. Plus one, and we have also got a number of contributions over the past weeks. And that we should keep pushing for these contributions. We had a discussion on how we could do that. Focus and outreach sick meeting. So maybe we'll come up with this proposal. For July on August, how to facilitate changes. Right now, what we are doing is also really important. This is all these things. So we can focus on that for now. Yeah. Stop. So thanks a lot to everyone for your participation. Any additional topics or comments before we close? I guess I missed it, but good. Do we have a scope on the whitelist blacklist? Oh, changes to bed. And you definitely was discussing. So if you have maybe five minutes, let's talk about it. Yeah. Yes, please. Yeah. So just from my point of view, I agree that we should change the terms. I'm a little curious about specifically the. Scope of what we wanted to change. I think with master and slave. We kind of all were on the same page about expect specifically, like what we're talking about. But I think this for whitelist blacklist, there are a lot of different things that maybe we're referring to. I wasn't sure if we had any in specific. Like specifically that we wanted to talk about. Or change. Some things are going to be harder than others. Like obviously the whitelist annotation and script security is going to be significantly much more difficult than if we find instances of whitelist or blacklist in documentation or. Blogs or things like that. I think our first priority is the, the more user facing and community facing things like. In blogs and docs and so forth. But we do want to eventually fix all. Occurrences of that. That's my opinion. Yeah, I mean, so like, yeah, from my perspective. So I'm like one of the maintainers of script security. So obviously I went through and kind of looked to understand what the situation was. And so as far as I can tell in the UI, we never really mentioned whitelist blacklist at all. In the code it's used heavily as part of API methods, annotations, etc. In ways that would affect backwards compatibility very significantly if we tried to change it. I think that problem that the proposed terms at least I don't think I would use either of them to describe script security. I would probably just not. Talk about the list at all. I don't think it's necessarily super helpful to users. It's like already right now in the UI we use things like improve signatures or whatever. So I think that kind of terminology probably makes the most sense at least for script security. So I just wasn't sure, like if we're voting on specific terms, I think it helps to understand the scopes. I'm not sure what we're talking about. We definitely need to go through the terminology. And we can come up with the recommendations for maintainers. Yeah, I think, I think, I think what you're saying is context matters for what is being used as a replacement. So I agree we should, we should have some recommendations of, you know, if it's this context. And we're not going to get all of the context because there are over 1500 plugins. So someone's going to use it differently than, than how we're, you know, thinking. So I think we provide some examples of ways to. Replace those terms. And then. Request that plugin maintainers. Make that replacement. Yeah, I guess. Yeah. It's like, so to me, I feel like a vote here is not so much on what terminology, terminology to use as it is with like Jenkins master, or I think it's like, we probably want consensus. I think the whitelist block list terminology is going to be pretty plugin specific. So maybe the vote is more of like, can we all agree that we're going to consider this term deprecated as of XYZ. And go forward and start plans on how we can. Like change the annotation, for instance, in the future somehow. Right. I know that's not going to be easy, but. Do we have plans though to make like changes to avoid like. Code references to slave and things like that. Cause I think they're kind of the exact same. The yes. The. Because the source code is so public. We had this discussion in. I don't remember which meeting it was, but we had this discussion. Oh, it was the outreach, um, sick meeting. Um, the code is so public that. Even though it's not determined in the, the user facing in terms of like blogs and docs and things like that, it is super easy. If you're like writing pipeline code or something like that to want to look at the internals of some things. And so many people are exposed to those inside the source code. Um, and so it is pretty user facing, even though it's not part of the docs or the UI. So I understand there are significant technical, um, Things we have to take into, um, account with changing code significant. I mean, we have like, There are classes that are named slave. There are classes in the name, you know, things like that. So there are huge technical things we have to overcome, but we need to. We need to have it on the plate to change, make those changes at some now. I agree. We can't. We can't just basically say we can't do it because it's too difficult. That's not. We, it may take us a long time, but we're, I really truly believe that we have to work until we get it done. Yeah. I also think in conjunction with that, we do add a deprecation time where we'll say going forward, it has to be this and, you know, I'm a parallel effort going back. We're changing it here. So definitely we won't be accepting new APIs, which would go to Hudson slaves or package or which was, would use slave anywhere. That's. Definitely. And we will accept it even in 2016. At the same time, there is a lot of cleanup and many such items would take a lot of time. Some are trivial though, for example, this one. It's just one minute patch in Jenkins test harness and that's fixed. So I'm working on adding capability to the plugin hosting checker to check for these terms. That we don't want in Jenkins so that it will be flagged even before new plugins come in. Obviously with, if it's calling into the core APIs or things like that, then right now that's not something we can ask them to change. But if they're, if their plugin is called slave dash something dash plugin that I'm going to flag that is actually in the checker and things like that. It was posted a few days ago. Yeah, speaking of ideas, one thing which we will need to think about is really fix and plug in ideas. Because it's more visible than a lot of API example, Sage agents. We renamed to this plugin, but well, there is no magic. It's the Sage slaves in terms of ID and changing that, I would say it's a significant exercise. I believe that technically it's possible. It will require a lot of architectural changes in how we manage plugins and changing called plugin management tools to support the LSS or whatever. But yeah, I think we also need to invest time on that because otherwise it will stay everywhere in the front of users and yeah, that's a big deal. We can prioritize things that will give us the most value first, but have a plan for getting better and work to that plan. Yeah, I would say that Jenkins developers will be happy if we support artifact ID renaming because regardless of slave terminology, there are cases when companies want to change the plugin names and right now the only way to change that is basically to use the user base, which is definitely not the ideal option. In the Kubernetes community, one of the things we've done, we started a working group that because we have the same problem in the Kubernetes code base, so we're going through and we're addressing that. But we have a working group that's now started to form to not only address current state, but future state. We may need to think about doing something like that because there is a lot of work that needs to be done and this can easily lose sight if somebody goes on vacation or goes away from the project. I really think we should maybe think about doing some type of maybe I don't want to say committee or something like that, but people that are going to be dedicated to documenting what we need to do, people that are going to be working on columns for this because it is a lot of it is a lot, but it is something that we need to do. So I'm not sure whether we need a special working group for that. Right now it's formally a part of advocacy and outreach. At the same time, I do not mind if we actually create a working group for that. Because I believe there will be a lot to discuss in the coming months for this topic. I like that idea. Okay. Anyone against? One thing is about the implementation because right now we formally have no concept of working group. At the same time, we have subprojects. So I'm happy to put it here. I wanted to basically merge subprojects, the subprojects, which is I think, common time anyway. Yeah, maybe just using subprojects and working groups as synonyms for now, would make sense. Yeah, we could say it's a subproject and come up with a name for it. I'm less worried about the name of the working group slash sub-project than I am, the names that we're trying to get rid of. No game. So I'll handle that. So I will just create a skeleton and then I will invite everyone to contribute to some such structures. Because right now, for example, yeah, I put guidelines, some guidelines here, but definitely it's not enough. So if we create a new page, et cetera, we can basically dump the documentation there or we could even just do it through GitHub repository. Though I would prefer to keep it on jink sale. Okay. Okay. So we already are going over time. Other topics you want to discuss? None for me. And for me either. Thank you very much, Oleg. Thank you all. So one thing to mention that, so the next meeting is in two weeks, right? So it's July 1st, I guess, right? Yeah, July 1st. Yeah, it might be another able, but I believe that Alex will be or somebody else will be able to run the meeting. Yeah, I just don't have access to the Zoom. So that's something we can fix, is it? Yeah. And I can be here to help run, I can help you run it, Alex. Okay, yeah, I'm fine running it as long as someone can help with the Zoom. Got it. I will handle it after the meeting. Thanks. We're still yet to create a job about how we manage our new Zoom account, but the fact that we have YouTube policy. So I implicitly assume that Homo is eligible to get access to YouTube is permission to get access to Zoom. So I guess that's it. Thank you, everybody. Have a good evening, day and rest of your week. Thanks all. Thank you, thanks.