 Hello. Welcome to the Jenkins governance meeting. Today is July 1st. We have folk contributors on the call, Mark White, Uli Haffner, Marty Jackson and me. And we have several topics in the agenda for the discussion today. So, we want to finally sign off the Jenkins Code of Conduct based on the conversation we had at the last governance meeting. Then we have status updates for Jenkins CDL graduation and discussions for terminology updates. Anything else you would like to put on the list? Okay, let's start from that. So, updating Code of Conduct. So, just to summarize what we discussed last week. Let's scroll down a bit. So, at the last meeting, we agreed to update to contributor covenant to the zero. And my item was to propose a pull request with code contributor covenant update. Also, with other items we agreed on like using CDFS second level of escalation, etc. So, the pull request is here. So, the pull request basically incorporates all the changes. It got a number of reviews. I'm not sure. Uli, did you have a chance to take a look? Sorry, I did not have a look up to now. Sorry. No worries. Quite a hard week. Yeah, that's totally understandable. So, basically, from those who are on the call, I'm the author, there are three approvals. So, I guess, yeah, we can discuss the details. We can just review that. And if it's fine, maybe just press it with the merge. And so, so Alex Earl as a board member has already approved the pull request. Yep. Oh, like you submitted the pull request. So that gives us two. Yeah, so I think you're right that Uli's approval would then give us a majority of the board that approves. Yeah, so just to clarify, we don't have a majority of the board anyway in the governance at the moment. We have a majority of governance, meeting members and roles. At the same time, having a majority of our Jenkins board members also makes sense in this case. I'll review it today or tonight. So I don't have a specific timeline for the merge, but if you have some time, maybe not today, but tomorrow will be great. Just forgot about it. No worries. But yeah, thanks to all the reviews, the text looks to be quite smooth and it definitely improves the coverage of particular cases. So hopefully you could emerge soon. Mark, are you satisfied by the feedback? Yes, completely. I think you're the the the proposals that you that I had made that you had not accepted you, you rejected wisely. So absolutely you can close out any all of the topics that I had. Yeah, so one thing is all chats recommended on this page, but I think it's just a working thing. So yeah, truly you can resolve all the things that I raised. Yep. Okay, so this one. That one, that one is just wrong, right? The notes already said, look, we don't want to mail two links in. Okay. So we have one topic about handling of relations. And I believe it actually was discussion. Because Yeah, just to clarify why There are changes that contribute a covenant to the zero. It will say its own definition for relations and actions to be taken. But it's explicitly considered to be a template for projects for projects can make adjustments. And in the case of Jenkins project, I made some adjustments in order to follow the previous guidance and previous actions. So for example, a contributor covenant. It has two stages. The first is temporary bond, another one is permanent bond. In the case of Jenkins project, we didn't have a permanent bond before, instead of that we have a bond after 12 months can be lifted. So I basically tried to merge two definitions and that's how we got it. It's mostly aligned to this contributor covenant, especially in terms of community impact consequences. It's mostly taken from contributor covenant, except this 12 months. At the same time, the problem is with these paragraphs because these paragraphs are taken from the current person of Jenkins code of conduct. And so one potential issue we had is that in our code of conduct, we explicitly say that we will be doing communications in private though contributor covenant doesn't require that. And yes, so the question on the table is whether we want to keep that or whether we want to just remove it or maybe declare it as an intention, because in some cases we have to respond publicly. But at the same time, yeah, so I also think that private communication should be the first step in any case, and only if it doesn't work, or then it might be a public communication, and only in each cases. So would be nice to get opinions from others on this topic, because this comment, yeah, it doesn't seem like it's really resolved. Okay. So, basically we have feedback from Jeff and from Mark that we could probably just remove it and follow how contributor covenant is written. But yeah, it would be great to get your feedback only Mark. For me, I think it's good if you keep it in private. Because then, if it's in public, I think it can be a little bit, you know, then the next step is arising and it's going on and harder and harder. So, I think if you can keep it in public, it would be the best thing. Are you saying, are you saying keep it in public or keep it in private. Keep it in private, sorry. Okay. I agree with that. I think there has to be a discussion that is done in private with the board, or members that are privy to the conversation. I do also agree that the outcome though, depending upon the nature of the infraction may, and I underline may need to be public. But I think by and large, most infractions and the results of the outcome of such infractions will remain private. Yeah, you know the same page. So basically, the question is about using curil there. Because as it's written now, the bias has two private communications on there. So is the question about removing that line. Or just in case to highlight that. Yep. In each case, we may go public. But yeah, I totally agree that it should be only for each cases. Correct. There is a violation done in private and effective people in the other party. I think that should stay the way it is. Is that what everybody's agreeing to. So I thought, I thought Oleg's question was really this, the statement is will be done in private and that would preclude are doing it in public, even for a serious or particularly grave infraction. I think we want the flexibility to be allowed to discuss him to bring it to the to public if we need to don't we all like. Yes, that's the point. Yeah, for me it's just reading because this basically we as Jenkins governance board are not allowed to act in public. For example, someone let's say goes public on Twitter, etc. Relates code of conduct today as official representative. Then keeps doing so. And currently we are binded to not replied in public. Oh, so you're saying take this out. Or adjust to highlight that it's our default behavior to operate in private. But in particular cases with the governance board may opt out to act in public. I think so my vote would be leaving this in but amending it for the use of edge case public announcements. And I think even when we say edge case public announcements, we almost should be very specific and saying, you know, I don't even know how much we have to say but if I just talking out loud, if there is the need to go public for a certain infraction. I don't think the full disclosure is needed. We can say, you know, like, and I'm just trying to use examples here. If there's an infraction of racism. We, and it's, it's publicly known that this infraction took place but the vial, the reporter did this in private the conversation with the board starts in private the outcome would be private but there'd be a public side to it that says this infraction or because of a an infraction. I don't know. I have tried to think of a. He is public announcement of resolution. I guess, yeah, we definitely not bring in the entire conversation to public or the report or whatever. You just the resolution. Yeah, I just think there needs to be an addition here that under certain circumstances, public reporting, maybe necessary. So, let's say handling of relations will be done in private and affected people will be notified. So there will be no be a public announcement over the resolution. Unless the governments. Yep. Okay, or something like that. Yeah, unless the governance board deems it necessary for a public response or something. Does everybody else agree with that. And I think 99.9. Well, 99.8% of the cases will this will not apply to everything will just be done in private. But there are those certain cases that may require the need to have a public sort of comment. And the majority of cases, they will not be public announcement of the resolution unless the governance board deems it necessary to announce the resolution in public. So do the in the majority of cases phrasing I think you did intentionally. Is that a potential sticking point or problem for someone saying hey I'd like to sample your data to see that really you're handling the majority this way. It's probably because it's private. Okay, got it. No problem. Yeah, we as governance board members have history access to the history of previous escalations. Okay, that's it. I believe you don't really share this information with anyone else. Okay, should I submit it as this. Once you once you commit that that comment I'll I'm going to give it a thumbs up as my approval, even though I have a non binding approval. Probably matters, I guess. Okay. So I will just admit it. Okay, and I believe this was the last comment which actually need a discussion. So, yeah, there is another one. She's basically linked to the meeting. So you can delete that one that's that you are correct. I made a mistake even offering that one. No, it's fine. But yeah, I will just need to reference the today's meeting, I guess. Okay. So, I guess here, do we really need to vote. Or do we agree that based on this feedback with a message or not. I think we've, we've we've got the equivalent of a vote in pull request so when only gives the approval that for me is sufficient. Okay. Okay. Plus, Jeff, Alex, early in the pull request. And yeah. So does it summarize the discussion well. Okay. So next generation report. Well, I'll make it really quick. So, yeah, we have this threat from Tracy about the CD evaluation. Basically nothing changed in terms of target dates. We still would like to have it done by the end of the July. Regarding the progress. Yeah, we have some items, for example, code of conduct, hopefully we get it done. Then there are some items which are already passed or passed with some questions because, for example, we didn't have documentation for the weekly process. Well, at all. So, I believe that we'll need to spend some time and recommend that and whether you want to create or not. If it's important thing to do. Yeah, there are some bits about guidelines, but all of it is preferable. So, for example, explicitly defined project governance and committed process, we have both, but not in the right locations. So, this right locations should be again, it's nice to have, but it would be nice to do that. So, on that governance MD, it seems like the authoritative location is the Jenkins.io governance documents, isn't it? Or are you, is this, is there expectation there that it's some sort of that it's authoritative because it's in the source code repository. Yeah, so the preference that there is, so for example, this is preferably laid out in a governance MD file. So, it means that we can just put the governance MD file which references Jenkins.io project governance. Okay. I see. So, it's not a rocket science. And also reference to contributing MD and owner's MD for the current emeritus commitors. So, to be honest, I'm not sure why we need to show the current emeritus commitors at all, especially in owners. But yeah, this how it's worded and basically it's the same in CNCF guidance. So, what would be my approach today that, yeah, for owners, while we have codoners, the problem is codoners that it references a team. And if you're not a member of Jenkins GitHub organization, you can access members of this team. I'll come on here. We may want to do something the same time. I'm not exactly I'll show what exactly to do. We'll need to do homework and see how CNCF projects handle that. But again, I don't think it's a blocker in any means because it's preference and we have another format. So, we can just reference that existing documentation application. Thanks for the clarity on that. Mark, maybe you know how it's commonly approached in CNCF? For which part? I apologize. Owner's MD. And not codoners, owner's MD. The owner's MD for the CNCF breaks it into two parts. There's the reviewer and there's the approver. I believe that and I got to double check this, but I'm about 80% sure that actually comes from the Linux foundation. So the same criteria would apply to the CDF. Yes. So owners would have to be, there would need to be certain breakouts of who can approve a PR, who can review a PR. Okay, we can just take a look right away. So from it to us, if you go to the main repository, here. Okay, there is no owner's MD at all, even though the project is going to go to Falco. Okay. It's like this for Falco. Yeah, there it is right there. Okay. And Yeah, so there's owners. I believe this is owner's MD. So it's approvers and reviewers. Yep. Okay. And each area of Jenkins. So if you go back out to the root of the Falco security org. And go into scroll down. Go to the client go. I think it was, and then look at the owners there. You'll see a different set of owners. So for example, I'm in this owner's file, but I'm not at the root of Falco for the Falco code base. So each various repo under the Jenkins will have to have a different owner's file. You cannot just specify across the board. So it's a good question what will be exactly required there. Because you're my understanding that we certify Jenkins as a project. Right. It's plugins. But yeah. I think it's only going to apply to the Jenkins infra repo, which is where everything mainly is housed. And I also think in our documentation, if we list out that in lieu of having an owner's file, if we have the code owners, but there's also managed through the GitHub teams like we do for Jenkins. I think that would satisfy the requirement. But we have to list that out. You have to list out each team, but we have to give an example that for Jenkins.io, there's this level of reviewers, this level of approvers. Yeah, the problem that you can really see members. It's not so much that you need to specify the members in there. I think we'll be able to get away. Let me double check on that. Yeah, so my problem is to actually go to the next CDF talk meeting and to clarify some beats, so I will just add to my list. I will I'll actually be there in that meeting with you because I'm doing the spinnaker graduation, so I have to go through the same exercise. Okay. So let's see what's next. So, yeah. Good. And the next, so having a public list of adopters. So we have a third party service. We have all the wiki page, which I was unable to find. But I believe it's there. I will find it. So my preference is to actually start from listing users who submitted the feedback to Jenkins is the way. And we have sent off from submitters to use company logos. So we can start from just using this data and maybe volunteer data from other users to have initial list of adopters. Yeah, it's very similarized here. So that's my plan here. Again, wiki content is likely obsolete. So I'm not sure whether it makes sense to really move it over to Jenkins IO, but maybe we can figure it out later. Okay, what's next? Yeah, then my CI. So CI status is basically the same as before. I started discussion with security team about the security checklist. We started discussion about triage team for Jenkins core. But the triage team, yeah, the problem that we, if we found this team, we needed to really operate. And we need to find contributors who are able to do the key, let's say a few hours per week or consistently. Otherwise, this team doesn't have chance to cover the use case needed for CI graduation. So, yeah. Do you have some ideas on how to approach staffing and starting the triage team? I saw Alex had relaunched a discussion about it. Are there other ideas that have been successful things that we should be considering? I'm part of the Kubernetes triage team. I could I could help here and I think I did. I did note in the that that I could. A lot of a lot of good knowledge here for Kubernetes. Yeah, so basically, we have it back from Mark is loading Alex, Mark, what? But yeah, again, the problem is about being able to do the key time consistently. Because otherwise it will be difficult to meet SLAs declared by ACI. And could you overview those SLAs again? What what's the expectation from CI? Okay, let me show it to you. I'm trying to decode how frightened should I be? No, you shouldn't be that frightened. So basically, we come by this criteria one. But so to correct you, I still on the table. The project must have knowledge. I'm a judge of the book reports submitted in the last two to 12 months inclusive. The response need not include the fix. So last time I did a query, even if you talk about Jenkins core, it's about 200s of bugs which haven't received a response yet. Only for Jenkins core in its companies, we are not talking about the entire plugin ecosystem. And the project should respond to a majority of enhancement requests in the last two to 12 months. It's even worse. Well, so that's the problem. Just doing this cleanup, it requires a lot of grooming. Okay, thank you. Thanks for reviewing it. Yeah, so my action item here is to actually create queries because I already pulled this data, but I didn't document the queries. It's just totally my fault, but we are not meeting this criteria right now. Even though a majority of bug reports, I guess it's also 50%. But yeah, definitely we need to connect this metrics and then to see how we could improve them. So we have below this metrics. Okay, any questions about that. So are either of those somehow directly or strongly connected to the core committers dashboard that Daniel Beck had created or not so much. Definitely related. So Daniel's dashboard, it mostly targets LCS releases, the progressions and other beats. So it's important. And of course, we need to document it as a part of Skylines. But at the same time, it doesn't really cover future requests at all. Right. Well, and it doesn't cover weeklies. You noted it's primarily LTS focused. But it would make sense. I also really monitor reports to LCS or the versions. But oh, we actually just hit 27 open issues. Yeah, I missed that. I missed that part. Yeah, vacation was nice. Only 512 of them are for the Git plugin. Only 512. Okay. But yeah, I can just show an example and type. It's new feature or improvement. Yeah, that's a problem with our jitter because we really need to build these queries and not everything really fits them. Okay, you can see that. So just the issues. Yeah, so we have almost 1000 fees in the open status. Many of them have been created recently. Many of them have been created but by usual suspects, but not all of them. And you're just cleaning it up. You'll require some time. They did not just define any what does acknowledge mean so it's enough. They're there all sorts of ways we could acknowledge it could be heavy or lightweight. So we have flexibility there is that correct or not so much. Yeah, we have some flexibility. But yeah, still, if you want to really deliver on that, then we need to define metrics. We need to define ways how to quickly access this metrics. It's not like just documenting the team. We really need to do significant work to clean it up. Yeah, let's see. So it's on my list for July. Again, so good things that we had a discussion about requirements. This CDF talk and the feedback was that we are not required to have 100% this right now. But yeah, the same time, I think we should really target 100% if we can. But yeah, it will be lower priority than major requirements like this one. Okay, any questions? Sorry, it wasn't a quick one after all. But yeah, hopefully I summarized the current struggles here. Okay, so terminal job leads. Does anyone want to do a status report? I can. Before the next meeting or before the next board meeting, I will work with Alex to get the list comprised as well as the template. Announcement. We, there's still a lot of stuff that's currently in flight. But that's the main thing that we're working on right now to get ready for the voting piece. So essentially, Alex and I will get the draft. email that will be going out with the terminology. We will then give that to you, Mark. And I think if it's my understanding from our last meeting, you will, you're going to be doing the setting up the actual voting infrastructure. Correct. Awesome. So we will get that to you sooner rather than later. Yeah. So one question is how do we communicate? I think once we're ready to trade on that, is it just mainly police plus social media? Or do you plan to do something more to communicate it? Definitely think that mailing list is should be done. I don't think we should do social media. Allow me to dive into why I feel that way. And this is just an opinion non binding. These changes are needed. They are, they are welcomed, but they are not everything. And what I mean by that is, I just saw somebody tweet something. And the tweet, I'm not going to read it, but changing all of the terminology is great. But somebody still fears for their life when they go jogging. Now I know that doesn't mean to what we're talking about. It would be better if we just put the vote out and started doing the work. We don't need to publicize it. We just need to do the work quiet. I don't want to say quietly. I don't want to be the organization that's tooting their horn that look what we're doing right now. I think it's great when we make changes, we let you know that the changes are made. But I don't, I don't want to. I think it brings value to a larger conversation through social media. I think if we vote, we put the vote out, we send it to people that are like we did much for the board votes, an officer votes, it should sort of be the same way. And, and, and that's what we do. And that's how the communication goes. Yeah, the problem is. No, no, no, I was done. Yeah. So the problem is this number of replies we want to get, because if we just announce it through the mailing list, most likely it will be around dozens. We want to see hundreds of responses or so to this vote. If we promoted through social media, yes, it will be likely about hundreds. That makes that makes sense. But make sense. So Oleg in terms of the response, the response rate to the voting that we did last year so we did a large scale notification. And still had a very small fraction of those who were voting or who were eligible to vote who actually voted. So, for me, I don't see any problem with announcing it on social media to encourage more people to vote. It's just a vote and we agreed it's non binding right this is, this is still truly a non binding thing that the, the governance board will have the ultimate decision authority. That's my understanding as well. Mark. I also retract my opinion. I do. If the voting turnout is going to be so low. I do think we should do mailing list as well as a social media announcement. So for my link list, if you ask about developer mailing list here we've got a lot of feedback already. Yeah, so we have Google Doc, but it doesn't incorporate feedback we've got over past two weeks. So there are more feedback and more votes which could be added. Yes, we could use it so whatever to do another round is formal vote. If this vote is advisory vote anyway. I'm not sure how much it has. If we don't target a serious number of responses. Yeah, then I say it needs to go to social media as well. I just think we want to make sure we're very careful in the way we're presenting it. I'm happy to live it to those who directly impacted by the matter. So anyway, we have time until the next governance meeting to decide on the procedure and how we communicate that we still need to press it with the top 10 options. Yeah, from this list we got a number of frauds runners, but I'm not sure whether this list is fully inclusive right now. Okay, first action item is Alex and I need to get the items to mark so more can take the second action item to create the voting infrastructure. Okay, then, I think it is. Other action items we have sort of a larger proposal time has expired. So basically we operate on what you've got in this thread. At least it's my understanding. Yeah, starting a working group. Mike tonight is to create a page skeleton. But yeah, I guess it doesn't look anything because we really need working group, not for delivering the vote, etc, but delivering the implementation afterwards. Still, it makes sense to do that. Okay, anything else on this topic. Nothing for me. So we have 15 minutes left. Do we want to discuss any other topics? We can give a brief update on the roadmap, but basically really brief one. So, since the last meeting, there were some changes in terms of roadmap implementation. I mean, since the last meeting when we discussed that. So now the filter and concentrates integrated. I will spend a bit more time to support filtering by specialist groups and other things, but even now it provides some information on behalf of the majority of the stories on the list. Tomorrow, I will finally submit a proposal about Jenkins online meetup for developers about the roadmap. I think that to be in the position to move forward and to approve the process. But yeah, that would be really interesting to get more feedback on this topic. In the process, basically, yeah, there were some minor changes in terms of categories slaming, etc. But in principle, the process didn't change. So we would be doing a slot for a roadmap discussion and the governance meeting until there is a technical student committee or the similar entity taking over the technical evolution part. Okay, before that, it would be just a governance meeting. So, if it's fine with everyone, my suggestion would be to move forward and actually accept this job as active because it already provides some value and we can get additional contributions and more visibility by promoting it. So, that's why I would like to move forward. Yeah, my plan is to submit voting at the next governance meeting to formally approve it. I already discussed it with Alex who's BDFL delegating this job, but basically we would be operating based on the result of the next governance board meeting. So any concerns about getting it matched? I mean, getting it into the active state. Nine for me. Yeah, plus one. So it needs some housekeeping because items constantly move to preview and release columns, which I really like, but that's why we need a more less regular meeting to do the scrap and to show that everything is on the same place. For example, many JSO projects actually in the preview status now. For example, machine learning, we have got alpha release, we have checks API, we've got alpha release, then UI theme management, we've got alpha release of the plugin and what else. Basically other topics are in preview as well. For example, things are in storage. So I will also do this cleanup before the voting. But the process itself seems to be working okay. We just need more contributors who actually submit entries and here we especially rely on special interest groups and subprojects to submit updates and to submit their roadmaps. Point well taken. Well, it wasn't about. No, I know. But yeah, all of us have to learn, but I think that having a public and open road map is something we really need as a project. So, deeply agreed. Let's try to get it over the line. And if anyone has some JavaScript skills, you're welcome to contribute to filtering to search to visualization. Because, yeah, basically, somewhere at the limits of my JavaScript skills. So, I guess that's it. And yeah, also update governance roadmap interest because for example, we don't have CDF graduation here. We didn't really have conduct code of conduct here, which you likely just went as released, but whatever. So if you see any missing items or any missing major initiatives we should add, please do so. And the end guess the design for terminology, because terminology we I haven't taken on an action items we still have agent terminology but we don't have items for the terminology cleanups and it's open question whether we want to have a single one or multiple ones but yeah. And to have it on the list. Okay. Anything else for today. Nothing for me. Nothing for me. Nothing for me as well. Thanks everyone for your time. So next meeting will be in two weeks so it will be July 15th right. We can just keep it as is. That are coming funds. Well, I will miss that meeting, but the meeting can certainly go ahead without me. Okay, but thanks for the heads up. And we will try to get more people on the call. So, let's see. So thanks everyone. Thank you all have a good day afternoon night. I Thanks for the time.