 Okay, hi all. Welcome to the Jenkins governance meeting. Today is August 12th and we have two contributors on the call, Mark, Wade and me. So I guess that's all for today, though maybe somebody will join us during the meeting. We have a few items in the agenda for today. So firstly, we will discuss some news including the DHNet CDF and the recent LCS release. Then we had a topic for selecting a new term for Jenkins master as a replacement for Jenkins upper as a single entity. We were supposed to make a final decision today, but right now we don't have a quorum, I believe, for this topic. So unless a significant number of contributors joins, I believe that we will postpone it until the next governance meeting on August 26th. And we also have a topic about Jenkins governance board and officer elections. So Mark, do you have any other topics? No other topics for me, although I'm interested in the governance board topic, even if we don't have quorum, because I think that's hearing your ideas would be a good thing. Next meeting is. Wow. Yeah, August 26. Okay, let's start from the beginning of the agenda. So, yeah, the first important item and that we are now officially a graduated project continues delivery foundation. So this is an effort which has been started two months ago and before that there was also a lot of foundation work towards general alignment is continuous delivery foundation. If you're interested to know more about this work, there is a threat in the developer mailing list, which I forgot to link. Okay, everything slow on my laptop. Yeah. So this is a mailing list. So what it means for us that now we are officially a graduate project at continuous delivery foundation, we are the first project to graduate. It means that we are fully compliant with CDF graduation criteria, which you can find on this page CD foundation talk project lifecycle, basically sets up a number of process requirement, including having a board with multiple representing companies and just second, what else, and then having documentation about governance decision making, etc. Also, we need to show that we have healthy number of communities and the project is growing and being adopted more and more. And also there are process changes like having good documentation and also achieving core infrastructure initiative best practices which sets a number of requirements, for example, for core quality for issue reporting for issue triage, etc, etc. So these are criteria we had to pass. And if you were following the mailing list, we actually have a checklist for this criteria. So you can just refer to this Google Doc which covers what we did in detail. There are some summary in the emails. So you can find them here and actually there was a lot of work included. So it wasn't just putting green checks. We actually had to improve a lot in our process and now documentation. So regardless of the status at CDF it was beneficial to the Jenkins project and to the Jenkins community. So thanks a lot to all contributors who are working on that. We have dozens of contributors. I believe I have a list here actually. Yeah, I know. It's probably not the full list, but thanks to everyone who contributed to the effort as reviewers or as code slash documentation contributors. And you can find more about what changed in the project and why we did it after all here. This is about the process and there is additional benefit to the project is actually additional coveration social media. So for example, can ease delivery foundation has posted its own announcement which got some traction. So you can go here and you can find some summaries you can find testimonials from different contributors including continuous delivery foundation members contributors and also Jenkins users. So I check out this blog post and CDF also launched a marketing campaign including some promotions and newsletters. So you can refer to this newsletter and here you can find basically some summary. So for example, you can find a number of articles which were posted on the continuous delivery foundation site. Thanks to all contributors who are working on that. Also, yeah, there are some cool content like comments, three additional video. Take a look at that and yeah, there are more events happening. So if you're interested, please check out this page. And yeah, what else about that? Yeah, there is also a blog post by Mark about the documentation upgrades. So if you're interested in improving Jenkins documentation, please take a look and as in any other way we invite everyone to contribute. Okay, so any additional comments about that? Maybe Mark, you could share your insights. Yeah, I thought I think it's been a great experience to go through it. The process improvements that CDF inspired have been a help and we're delighted. Really good results. Thank you. So yeah, going to other news. I was actually thinking about organizing a happy hour for CDF graduation. But yeah, I kind of expected this level of participation in the mid-August because Europe is just a desolated because everyone is on vacation. It's pretty much the same in the United States. So yeah, maybe we should actually move it to late August or beginning of September, but I definitely want to have a kind of celebration party for that. I was actually about to do the next governance meeting, but yeah, since we are likely to have terminology topic at the next governance meeting, I will probably schedule a new meeting. I like that. I think we should celebrate it. That's a great idea. Okay. Okay. So yeah, other news today we had a new LCS release. This LCS release included a number of new security fixes in the Jenkins core and also in several plugins, including pipeline and maybe an integration plugin, which is used by more than 20,000 users and Well, in my extension, I guess it's even more. So let's take a look how many smile. Okay. I always forget artifact idea for this plugin. And I guess I'm not the only one. I think you need the leading, the leading E on email. All right. So probably something to improve searchability for this plugin. Right. Maybe more than 20,000 users. Yeah, 10 times more. That's impressive. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Thanks so much every Jenkins instance. So thanks a lot to the security team and the contributors who fixed these issues. In addition to that, we are happy to announce that the new windows installer is officially in GA. It was originally announced something like one year ago by Alex Earl. We had to postpone the release of this installer until the completion of the Coralis automation story Coralis automation story was completed last month. So since that we ship everything in automated way and we had an online beta last week. So I check it out. But yeah, finally, this story is in GA. And it means that now you get better installers. No 32 bit support. But it's quite aligned with our support policies for Windows. Okay. They will, will say a few additional changes, but these are key ones. And if you update this, make sure to update your signing keys like suggested in a big guy lens. So just follow them and everything will be fine. So anything else to it about this LTS release. No looking forward to people adopting it. They can also continue upgrading on their Windows servers using the internal upgrade. So the upgrade guide describes that as well they should. They should use whatever works well for them. Okay. So, yeah, every guy once available for this LTS release and yet you can see that they include a number of changes. Okay. So this is one item and also we have new support next LTS baseline. Oh, right. Yes. So it will be to 249. Yeah, it's selected. So what it means for users, we have a number of changes. So it's quite recent release. And in 2.2 48, we actually had a number of changes, including dropping support for the night framework to Windows services and the money other changes related to APS and develop. Well, yeah, API changes also some other items and improvements. So it's quite recent release. It's expected. The release is expected in one month. So it will be September 9th or 10th. I don't remember the exact date, but the release candidate should be available in two weeks as usual. So if anyone is interested, you can start from exploring this weekly release. You can see that original community ratings were quite bad. And for example, I still know about a few regressions for Windows services. I need to fix. And with part two dot one. But yeah, the release itself is available and you will appreciate any feedback from users. Well, and that's one where early testing particular user interface areas, there are some significant improvements in UI there that we would love to have tested. So we encourage people as the release candidate becomes available to help with the testing. J. It's September 10th. So now actually September 10th is Friday. So it's September 8th. Yeah, speaking of that, I guess we need to organize an online meetup to these days to present new features, etc. You want to put an action on me for that one, Oleg? I did the last online meetup for 2.235.1. This one probably justifies a similar kind of introducing 2.249. Okay. So yeah, if you could organize it, it would be great, especially since I am on a vacation from September 1st to September 10th. So we either do it one week later or if you organize it would be great. Yep. And I assume it's okay if it's very near the GA that just before a few days before it would be fine or the day of GA doesn't have to be one or two weeks prior. Yeah, it doesn't have to be one to weeks prior for sure. I would actually give it a few days to collect community ratings. I'll make it after the initial release. Good. Yeah, because in this case we firstly can add additional details about the experience regressions. Well, fingers crossed we won't have regressions, but so I would rather schedule it, let's say, too early, or maybe something like September 13th, 14th. So early next week after the LCS release. Great. And we have quite a number of features. So what we have yet, so it's your improvements, new installer for windows, also new windows services. Well, and the deprecation. Yeah, that's the deprecation of the old net stuff. Yeah. Well, the application of all the net stuff also implies some changes. For example, now you can easily install windows services without having to evaluate permissions because now the dialogue works properly. There is a bunch of other improvements. But yeah, what else we have. So for example, dark theme. I guess it would be totally justified there. So the first LCS way we have that and plug in the installation manager in Docker. It's a story Alex and team we're working on. Yep. Yeah, there are any other major changes. Well, I guess so. Right. We'll need to collect them and present them in the meetup. So I'm just browsing through the change log, but yeah, it's the cutoff from the previous bit baseline. But yeah, we can take a look. Maybe external finger print storage though you have a separate meter for that. But yeah, okay. So, Yeah, anything else about the next baseline. Okay, nothing for me. Alex, anything from you. No, not on that topic. Okay. So, we have three people on the call. Should we actually press if we selecting a new term. I think we should. Yeah, I think it'll be fine. I would like to have more people here but we, we made the proposal we'd make the, or have the vote in this meeting so people were aware of that. Yeah. So I think if they're not here then they're allowing whoever is here to make the decision. Well, I've heard that we had more than 100 votes. Yeah, it was 120 I think. Yeah, or something close to that. Yeah, so it's, yeah, 130 actually. Okay. Yeah, so community votes and basically it's what's through the mailing list so we've been promoting the votes too much public. Okay. So, for discussion on this just before we do vote. So I sent out that table of translations. Hopefully I didn't butcher the Russian translations too much because I know nothing about Russian so I was sent to the birth mailing list. That's correct. Yeah. So if you don't want to, I will stop screen sharing and copy paste it. Okay, sure. Yeah, I don't think that there is any sensitive discussion in this particular thread but yeah. Yeah, I agree. One drawback, if you will to many of these terms is that they in many of the languages they have a gender assigned or associated with them like languages like German or Spanish or French. I believe I'll have like a gender association with a noun. I'm more familiar with the German part of that than either Spanish or French but that was something that we kind of wanted to think about as we voted on these terms. So that that would be something we, we can discuss or or whatever in. Yeah, so we can look at the. Can you make that bigger at all. Yes, sure. Oh, please. There you go. So these are just these are just running directly through Google translate. And then for languages that I was somewhat familiar with I kind of chose the one that kind of aligned with the idea of the English word. I think number seven, because of the connotations of the word furor, we should probably cut that one out completely. I guess even in German, that could be other synonyms. So that's true. That's true. It's not the final blocker source, same for example. For coordinator region that there was another vote proposed, but I guess, I don't know for controller. So here in the table you have regular but there is also controller, which is true. Okay, yeah, that's my key. So, yeah, synonyms are available for languages. So these are in order of the community vote to the same table so controller was the top item in the community vote by I think a fair margin. Yeah. So you can take a look so basically the closest vote was manager, but it loses its controller something like three times. Right. Yeah, basically manager coordinator primary they go to approximately the same amount of votes. So there would be three choices and after that basically there is a huge gap until the next votes. Right. So for me personally and from what we discussed in the board, I guess there is no specific reason to not select controller. We go to as community holds. At the same time, we still need to talk about the localization issue because for controller as basically for any other work, we still have issues with genders and languages which have genders. Yeah, I mean it's hard to how do you fix that. So, regarding that, during the last few weeks I reached out to native speakers, including French, Spanish, Italian and Russian. No, for Russian it's quite easy. So, basically, what I got from everyone is that we need to select one gender and to stick with it because if we try to somehow reference to genders, it will over complicate our technical documentation and make it more confusing to users. Okay. So this is the first feedback I've got. The second feedback which is a bit more mixed is what the gender to choose. Right. Yeah, so the commendation. So for that, that was mixed feedback. So, one of common items in the responses was that let's use masculine gender because Jenkins bound that logo is masculine so it would be aligned. But the alternative suggestions is to actually use feminine term because we could. So, yeah, and potentially somehow mitigates the fact that Jenkins logo has a gender which is not a common case and products. So, yeah, these are two options on the table. Personally, I would rather abstain from this decision. What to choose. But yeah, I'm just saying that I've got. So I think we're saying that we're the term we're going to choose is controller. But now we need to determine the localization outcome of that. Is that what you're proposing, Oleg. Yes. Okay. I agree choosing controller based on the feedback from community as well as just it for me it makes sense. That was the one I was kind of that I voted for. So, as my number one. Well, I didn't but at the same time I'm happy to stick to the community decision. And as I said at the previous meeting I am really looking forward to call my Jenkins fellow runner master edition a microcontroller. Nice. I like it. Yeah, so I'm happy to stick with this decision. And at the same time. Yeah, so votes we've got so basically 95 versus 35 among Jenkins contributors. I would say community not necessarily contributors. Okay. Yeah, that's right. Yeah, or voters. So basically we send it to user and developer my name is right. Yeah. Also six right. Yes, also. Okay. So, regarding Jenkins governance board, I believe that we got three plus ones for controller. And two abstained. They represented correct Alex. Yeah, I believe so. Yeah, they can. So I haven't seen additional votes in the mailing list after we closed the voting. Let me double check. Okay. And no additional votes. And yeah, Mark, what is your vote controller. Yeah, I have no solution for gendered languages. Italian. It goes he. It exists in Italian and I don't know how to solve it. Okay. So, off the cuff, I would say, let's choose the feminine gender for those specific reasons you talked about a leg, but that's just off the cuff. So what would be our steps regarding, sorry, regarding the gender, because one thing we could decide it right away today. Another way is to actually drop it to the mailing list to see what would be the feedback because process wise and change wise. I don't think that we need to have a decision on localization today. I agree on that. I don't know if do I mean, do we need to open it up to the do we want to open up to the whole community I foresee that actually being a, a harder conversation than the replacement of the term. But I mean, maybe I'm just pessimistic. Yeah, I'm sure, for example, if you take Russian language tradition, Russian language has three genders. But some words have to have a gender, including controller. At the same time, historically, a masculine term is used for gender neutral term for such items. So, for example, if we suggested to use feminine for that, I guess it would be a lot of misunderstanding and the Russian speaking community. No, I'm again, not sure whether we can come up with the decision which would fit all the increases. Yeah. And what I know about Italian supports that I'm not sure that I could, I could sign off on Italian attempting to use the inverted gender, the wrong gender for a term that already has a gender associated with it in Italian as a noun. So, could we defer the gender question to the localizers who are proposing a localization with. Go ahead. The idea being that they choose it based on what their understanding is of their local their locale. So, under the topic of above gender, you have recommendation to use a single gender to avoid complicating documentation is that a single gender per language or a single gender gender overall. Yeah, this is something we could agree on. Because you said you solicited some feedback from native speakers was that was that recommendation that that you use a single gender across all languages or was it. I haven't asked for specific. You had a comment up above. Yeah. I just wondering what that was referring to. Okay, so I asked for feedback about their particular genders. Well, genders and their particular languages. Okay, I got some feedback how it could be written in general term at the same time. Yeah, almost every response I've got was about that it would be better to stick to a single gender per language. Or cross language that's my question. Yeah, I haven't asked about. Specifically. Okay. Yeah, I'm, I'm kind of in marks camp where that's the gender is kind of left to the localization folks. Yeah, the same point. So for example, for Chinese, it's not a problem because there is Chinese localization sick. We can easily defer this decision to the sick. Other languages have no such entities. So, well, if we, yeah, I'm not sure how to organize it. How does Kubernetes solve this because they use control plane or something similar, right? Is that so how do we, you know, how do other open source projects manage that for this. Are we going to go in and like, are we going to do a global search room place for the term, you know, master and various different languages with just something else or what, you know, I don't, at least for me on the, I don't intend to do that because my experience attempting to as a non native speaker do localization has almost always been an abject failure. The native speakers prefer exact phrasing and exact terminology that I inevitably as a non native speaker fail to comprehend. So for me, I still would leave it to the localization communities. Localization individual contributors, if you will, if they are contributing a localization they get to choose how they attempt to translate the word controller into their language. So basically your proposal is first contribute or makes the decision right. Right, right. And that may be sub optimal, but as a matter of, of course, I think it's, it's an approach. And, for example, say that there are two main targets, let's say Jenkins site or website or Jenkins core, whomever submits a pull request in a language, we can call this discussion and CC all known contributors or who use this language and basically stole this pull request until there is consensus. Would it make sense. Yeah, that would be fine. Yeah, that works. So, the discussion when there is Jenkins core or Jenkins pull request native speakers expected to reach consensus. This process is still quite difficult. Yeah, maybe also the mailing list. Yeah, at the same time, for example, I can imagine my plugin maintainers doing changes ahead of us. And we had already had plugin maintenance, changing documentation for Jenkins master to other terms, not mess the controller. So I'm not too concerned about that at the same time. Yeah, I guess what we will need to do is to track these decisions and maybe to have a page is our recommendations. That's a good idea. Yeah, introduce a page with a term recommendations. In various languages, right. Yeah. So, yeah, we already have a glossary page. So maybe we could somehow injected there. And I'll show how one easy ways to just add a hyperlink, or maybe at the expanding section. So, for example, we can keep a disease, and then say localizations. So you click a button and then the expanse and shows you recommend localizations for different languages. Would it make sense. Yeah, I think that sounds good. I believe it will require some implementation work because I'm not sure whether we have a standard macro macro for that. But it's not a big deal to implement it if you decided to so I'm not sure who would take connection item to implement it. You can give it to me I don't know necessarily how to do it all but I'll, I'll take a look into it. Well, we need more example experts. Yeah, but yes, I'll kick off the discussion when there is a Jenkins core Jenkins IOP pull request. So, stole the request and kick off the discussion. Okay. So both Jenkins IOP and Jenkins core support on hold label. So, my name please. Right. Yeah. Should we be developer on documentation seek. That's a good question. That means that would be fine. Yeah, that would be okay. Which one. The, well, developer list is more likely to be detected by plug-in maintainers and by localizers than the doc seek. I don't remember the last time I saw a docs mailing list posting from someone who's a localizer. Okay, so developer mailing list then. Oh, cool. Maybe a mailing list of presents. Yes, right. Just to comment on that. The Chinese is an example. Well, Chinese is a good example. The problem with that, that we have mailing lists and other languages. So if you go to this page. So for example, Brazil, Japanese, Korean, Chinese. My bet is that this mailing list is not very active for these days, but I'm happy to be wrong. Let's say, so for example, Brazil. I guess it's Brazilian, right. So we are last update, actually my 30s, but before that was previous year. So for Japanese, it's pretty much like that. So I guess it means that Chinese is the only honorable exception. Well, I can Russian, we don't have a mailing list. We have telegram chats, which could work, but in Russian, it's still quite straightforward. So I wouldn't expect too many problems. In a local or a Chinese. Okay, so would it work? Yeah, I think that's good. I like that making a decision without making a decision. Well, I believe that it's the best we can do with the gate it to contributors who actually familiar with the matter. Conditions. Yeah. Okay. So I guess it means that Jenkins controller is now official. The general recommendation publicizations. Fortunately, in English, we can just use it and they believe that we already use it in the documentation. Okay, so anything else. So I'll take that. Quickly running out of time. So my proposal would be to just quickly touch the governor's important officer elections and push the rest of the topics to the next meeting. Is it fine with you? Yeah. Okay, so for governance board and officer directions. Yeah. So the thing that we actually need to have them. And so we have a page documenting the process here. Project. It's a long page. Yeah, Jenkins board direction process. The current terms. You're effective on December 3rd or so. I forgot the word office. Maybe. Oh, okay. The current. Yeah. Okay. Members and officers. So to re-elect. So unless something changes, we need to re-elect one board member. Okay. And five officers. Including Mark. So yeah, what it means. That we actually need to organize the process. Last time it required significant time from us. The most difficult part was organizing chiefs vote. So similar to how we ran controller decisions. But the controller decisions, it was easy because it was a public vote. So basically anyone visiting was eligible to vote. But our governance board direction process is quite different because it defines the ability. It means that we can adjust the center public link. It needs that we have to prepare restricted links for all participants. CIFS supports that. But yeah, what we experienced during the last election is that you can adjust that 100. Participants like we have in our journey in our database. And our process basically requires us to send an email to every user in the database. Then they subscribe for voting. Then we send them another email this voting thing specifically for this particular person, then they vote and then we count the results. So last year it was quite difficult to implement all that. And the one of the topics which we have brought up in the retrospective that probably we shouldn't do elections like that anymore. And it brings up the question is what you want to do with the next elections. I remember all of you spend a lot of time and other people, not just him, but there was a lot of time spent trying to figure out who had the emails and stuff like that. So I would definitely like to avoid that, you know, but I don't know, I'm not sure how to do it since I mean, do enough people read the user and dev mailing lists that you can. But you have to have, it has to be logged in by a single person, right? That's the Yeah. And also we need to somehow identify eligibility of such a person. Because for example, your last voting we defined a cutoff period. So why it's needed is because otherwise somebody could just create let's say 100,000 accounts. Right. So we require the elections. So we define a cutoff date. We basically base eligibility on that. So there are two of these issues. One issue that basically we need to define cutoff date early. We need to query our data to prepare this mailing list. Querying data becomes tricky because we know that we lost three months of fold up database history. So I guess that some contributors may be visible at the same time they are not in the database. So we will need to use alternate channels to make the announcement and to provide a way for them to actually mitigate that somehow. Yeah, we did alternate channel for that last year, but I doubt that anyone used it. So the process is quite complicated. Yeah. And it would be great to consider that, especially if you talk about identity management migration. So the topic which has been discussed is the infrastructure mailing list. Because one of the options on the table there is basically using Linux foundation user database and migrating there so that we don't have to maintain our own database. But it makes elections even more difficult because you won't be able to really track contributors, etc. Probably we could but it requires some additional implementation. So this is the topics which I wanted to brought up. Again, we don't need to make any decisions today, but we definitely need to start planning for that. Because, yeah, if let's say elections happen in November so that we respect one year terms. It means that in the beginning of October we should have a finalized process which will the consensus in the community. So that doesn't happen on the last day. Yeah. Oleg, are we open to considering removing eligibility requirements entirely? Considering the voting process on controller, on the use of the new terminology? Well, again, it's a problem is whether we're concerned that somebody would select. Because, yeah, for public votes it's easy. You just clean your cookies, change your IP somehow. It tracks your participation by IP. And whether you can vote again and again. So I don't think that we can drop eligibility requirement completely. At the same time, we could probably redefine that. One of the potential ways to redefine that would be easy, but I don't think appropriate. It's just to take maintainer database and, for example, GitHub contributor database. It's something we can do easily. At the same time, I don't think that GitHub presents the Jenkins community. So, and again, I brings up another program. So we still need to have a mixed approach. Probably we could just create the early sign up form starting reach out to contributors through different channels. And introduce a way to verify eligibility. Yeah. So I don't know how to do that, but definitely removing eligibility requirements entirely is not an option for me. Okay, good. Thank you. Thanks for the clarity. So personally, I just lean towards just don't pick users databases, you know, and announcing it to the mailing list. So maybe mailing please. It would be great start. And they hopefully will get enough people to sign up. Then we can do the same, for example, for blog, blog posts, social media. And we can filter people who sign up somehow. So, yeah, for example, we can require anyone who responds to provide the Jenkins account ID or GitHub ID so that we can verify their contribution. It would still require manual work, but it's feasible, I think. Yeah, I think that sounds like a good approach. I'm sure that the devil is in the details as they say, but yeah, even our previous process was a kind of, let's say, not ideal, because you can be a contributor to the Jenkins project, but it doesn't mean that you need to provide the Jenkins account ID, especially now when many components moved to GitHub issues. When basically you don't need the Jenkins account for anything except the Jenkins general right now, unless you're admin, or whatever contributed to this infrastructure access. So, yeah, I don't think that our current process is totally inclusive when it comes to the Jenkins coming in cases. In this public sign up plus verification, you're envisioning that if they have a GitHub account, they would be verified or notes that you need to be somehow involved in one of the Jenkins repositories before you would grant them. It needs more discussion. We're probably beyond time and therefore. Yeah, we're slightly beyond time. So, but yeah, if you have GitHub account, you can query Jenkins GitHub organizations and you can have a proof of contribution. For example, full request, comment, review, whatever we can define this correctly later, but we can define. Same for Jenkins Jira. We have account ID, we can verify that there was a comment, we should create an issue address. Again, we can verify a factor of contribution. For the rest, yeah, we can use manual ways. For example, please, if you have never contributed using GitHub or Jenkins Jira, please describe your contributions and provide the ways to verify that. So something like that. Got it. Okay, thank you for the clarity. Yeah, so what is my plan is to actually think about it a bit more and come up with a proposal and the developer might at least early to start this discussion. But yeah, I definitely think that we should warn and stop relying on all Confluence account members, especially since we definitely know some contributors who can know 15 times, especially our infrastructure team members because they have multiple accounts for testing. Well, I totally believe that they don't want to use it. And we actually did some verification during the previous election process to ensure that there is no such duplicates. At the same time, again, it's potential for changes we cannot verify. So, yeah, it's, we are five minutes over time. Do we have anything else to discuss on this topic? I don't think so. Okay, so, yeah, I'll try to start my lengthy discussion once I finalize my proposals up to a way that looks sustainable to me. Maybe I will run it through the Jenkins port and officers first. But yeah, let's see. So it definitely doesn't happen next week, but maybe later. Okay, so and I will move this topic to the next meeting. So Alex, would you be able to summarize the decisions on the terminology. Yeah, I'll send out a reply to the mailing list. Yeah, thank you. Because I guess it's the only time sensitive topic in terms of communications. Okay, then thanks for your time. And yeah, thanks a lot to everyone who participated in the terminology discussions and decisions. So great to see this topic concluded. Thanks for all these follow ups for localizations, but you have a pass forward. So thanks to everyone. Thanks Alex. Thanks Mark. Yep. Bye.