 I can't record. Yeah. So, yeah, sorry. Yeah, it just helped. Yeah, thanks again for doing this session, Angelique and everyone, because it's so much appreciated. Okay, straight to the point. So what are we talking about the terminology? It's about changing how we name the things in the Jenkins ecosystem overall. So, the first one is, yes, we called Jenkins Instance a master. Now it's a controller and that's easy, right? Just change it everywhere. But no, no, not that easy. There is, in some cases, it's the built-in node when we are talking about the node Jenkins as a node itself. And there is also the in the Git world, the master branch. So in the community, there is an agreement about calling it the default branch when it's about Git. There is also the word that we try to remove, that the community try to change since many years that is still there in here and there. It's agent, maybe that goes to agent. And there is also the white list and black list that now the default naming is a low list and deny list. But as we have so them in the code, most of time you can adapt to the context. For example, once it was about filtering something. So I think we called it filter and list or something like that. So, white list or black list usually can be changed to something very contextual. And that's all. And now that's not all because the terminology is also on the UI. So it sounds also about what are the world in the other language for everything, all of this world. And it's mainly also for plugin maintainer. I have a pull request with someone changing words in Chinese, in Russian, in French. What do I accept or not? Is it the right term or the bad term? So it's something that touches a lot of words in Jenkins at the end. Any remark, questions so far or suggestions? Yes, so one comment that sometimes it's not enough to say master to controller because there are also sub terms. I'm not sure whether you will be talking about that. But yeah, it increases complexity, especially for user documentation, which have for so many underlining terms. And another issue we discovered when we were working on terminology that some languages like for example, French or Russian, they also have genders. And sometimes if you want to build the inclusive language, English doesn't have genders in general. So it's easy, but when you start switching to languages, you discover that particular terms may be actually non inclusive in target languages. And you have to come up with an approach. So yeah, we found an approach for French for Russian based on practice of use, because it's not the only use case like that. But yeah, there are a lot of hidden stones when you start talking about languages. Yes, and also for some languages. If I want to remove, for example, slave on all languages, I don't know what is the word is in the other language. I cannot do a GitHub search right now, because I don't know all the possibility in all language. So we had several discussion in the, I have put some link at the end. So we will go to with all the document and links and places and discussion and how do you give me five minutes? Sorry. Okay. This is Murphy Law. The five minutes you are talking all the home is coming in the room. So, okay. Back to this guy. So yes. But what do we change? The first idea is about the user interface because it's highly visible. It's the first thing the end user saw and there is very few backward compatibility issue. And it's about changing some the same world in some tests that were using the world to verify something. So it's a very good starting point. And there is a lot of contributor that have started doing these changes on the UI. So the console log. So both the job console and the log, it's quite visible still for end user. And it's often some string. So it's quite the same. It's only the backward compatibility. It's only about changing, updating some text on tests. But there is also some troubleshooting tools that may grab some log or something like that to detect some behavior. So this is also where the backward compatibility can be a bit adapted. Then there is the documentation part. So I didn't look much at Jenkins IO documentation. I think it's quite up to date. But there is also plug-in documentation like markdown file, the readme. It depends on what you consider the user is. But if you consider that a developer that is using the plug-in is the user, then it's fairly visible for this kind of user too. There is also the code command. So when we did, we tried to update. We began to just do the UI text. But by doing also the change in the code command, you lower the, you make it easy to search if there is still some term that you want to change that remain in the code. So I saw that a lot of contributors are changing commands also because it's more handy for the flowing. Then there is some nearly code, but it's something that is generated from codes like the configuration as code. So you can have some term that ends up on the YAML because it's via name on the code or the class name. So it's quite visible. And the good news is that by using the annotation symbol, it should be easy to keep both the old term and the new term for a while before changing in completely. So you can have the background compatibility for the Jenkins CLI. It's quite similar. There is maybe some Jenkins CLI with the term that we want to change. I also have in mind that maybe tomorrow there will be some other term that we wanted to change. I don't have any in mind right now, but it's about the overall process. It's mainly, I think, visible to people that administrate the controller. And the background compatibility can be kept by deprecating the old CLI name and having both the new and the whole name at the same time and then after a while removing the deprecated one. And change log, there have been a discussion in the Google group. I'm not sure that there is an agreement. Maybe I missed the right meeting on that. So it's mostly the release, not the Git change log, because some people asked. It's about the release of the plugin, for example, if there is a release not that is five years old with old terminology, do we change them or not? Do we change the past or not? It's something that is not decided yet, I think. And there is also more and more system property. Usually some system property are used as worker run, so it should be less used, but often the package name is used and if it's package name you have some term that we want to change then the term appears on the system property. I don't have a methodology yet in mind. Maybe we'll come with discussion. And for HTTP endpoints like requests to update, to ask some data from Jenkins and the URL in the browser. It seems to be something that we need to look at one by one. I'm not sure. There is a generic way for that. And the last one is the code itself. The last part. The package name, the Java API. There is a lot of that compatibility issue, so I think it's the part that most people keep for later for now. And this is the link. So I think that now the main entry point is the post that Oleg did on this course. Most of the link are inside. And most information, there is a lot of information here. And I will be happy to see these slides also invited on this page because they are awesome. So thanks a lot, Angelic, for preparing this update. Yes, I wish are them. There is this GitHub project page that I really like that Oleg did also. And you can see if there is some open pull request or I think it's most of pull request. And the work that has been done so far, you see on the don colon, there is a lot of contribution. And that's really great to see so many contribution. Question, Angelic. Has any thought been given to the Xtreme, names in Xtreme? Because you touched on the classes, but Xtreme is distinct from the classes. I don't know if people read the XML and would get offended by seeing a class name something slave in there or not, but we can alias. So we can alias foobar slave to foobar agent, even though the class name is still foobar slave using Xtreme. OK, you mean for configuration file, for example? Yeah, the actual things that are on this, the raw XML, that if you weren't using Conflicts code, you were just using the Jenkins UI and you hit save. I suppose it would anyway be at least related to the class names James, you know, and their persistence. No, no, you can, you can change what something is serialized as without changing the class itself by adding an alias and say I want, I want to save the, I want to save Bob as Fred and Fred D Marshalls to Bob. So in the XML, Fred is always Bob, but in code it's always Fred. It kind of helps move things forward in the fact that people won't complain about the XML contains offensive language, but it removes the mapping that this maps to this class so it's easy to find out what something is doing. I would imagine that in. Ideally, the things would be kind of migrated. You know, they are like slave on the disk, you rename the class, you put the alias, it's understanding that, you know, it was previously named blah slave, it's loading and saving at blah. But you can't change the class name in the actual Java code without fixing all the usages of that class. Sure. You can change the alias, what it's persisted at without changing the class name. Yeah, sure. But we know that it's already a big problem and big difficulty that's the last box in the in the slide right now, right? No, I'm trying to say there's a there's an intimate potential. There's an intermediary part that could be done that you can change the persistence format without changing any of the Java code. Okay. I get it. I get it here. So you're saying, you know, if we think that you're changing class names is a is a mess and very, very tricky, which I can agree with. Just as this changing for now immediately more immediately more soon. The serialization format is a potential intermediate say that makes sense. And there is another point that is not in the slides that is the repository names. And some alias one repository contains one of the words that we want to remove. Alias one, I don't know if there are more. Oh, there's also plug in names as well. It's, yeah, it's the same. It's related often. Yeah, plug in names are the most complicated part because it requires very serious reward. I have some way me is saying for that. I'm not sure what is shared in public or only within the piece. But the remaining plug in artifact ID is so complex that I don't know the vast majority. Plug in plug in IDs is very simple. If you create a new plug in, move all the code from the old plug in to the new plug in and just depend on the new plug in from the old plug in. This is just a bit tricky to manage, but it's it's a pain, but it's relatively trivial. And then all you have to do is anyone that's depending on old plug in, they need to start depending on new plug in instead. Yeah, he's been done. Also noted as one of the easiest way in my dog. There are still concerns, for example, for configuration as code, et cetera, because it will likely become a source of mess unless you use full bill of materials. Sorry, but still it seems to be the easiest way. And maybe so for the sage built agents, it would be an excuse, for example, to design the plug in a bid for Windows Asians. I will be happy to list to do zero and probably fork the code or maybe just duplicate the plug in to be honest. Unless there is a maintenance. So, yeah, this approach is easy, but it also it's also quite complicated in terms of user impact. We shouldn't be thinking about classic Jenkins cases, we should be thinking about configuration as code these days. No, I have five minutes. Maybe what I want to discuss is this. I was trying to have a table with all the zoom widget on top of my. Yeah, so I was looking a way to have all all the world at one table to be able to to look at them easily find them easily. And so I started a job thinking it was a specification, but and I have no strong opinion, but maybe it could be also on the documentation on Jenkins IO. I don't know what do you think about this part. I think that since you have started the job, you should rather finish it. Okay, because moving from one form to another is overhead. And while this story doesn't necessarily require a job, it raises the profile of this story beat. And in this case, I don't see a problem. What I wanted is to have it history because I think it's interesting to see when a new term has been added or if there is some discussion on one translation maybe. You know, it might make sense to for the JEP here, this is a regional start, but for the JEP to be a point to another repository that actually tracks the the like a Jenkins CI terminology, approved terminology repository that actually does this separately so that way it can be maintained separately from the JEP process. It's like look that we have this process and it's and and that could also be where we would maintain a some automated tool that does that does scanning over over Jenkins repository or other things like that right. Because I think in the long run, we would want this to be something where we do automate it to a significant degree right at which point. Yeah, we could automatically detect this word in PR for example. I don't know. I don't have a tool in mind, but I'm sure that it's possible in PRs in commits. Yes. We can process a ski dock as well as a source of information. So it wouldn't be a blocker. Even if you wanted to put it as this. So it might be interesting to use the ASCII doc as the source of truth. ASCII doc is machine readable. So okay. Yeah, it might be not the easiest. So in my case, I would just advise to not over design. Because yeah, it's awesome to think about all these tools, but at the same time, I would rather let people focus on actually cleaning up terminology than investing too much time in the process at the moment. So yeah, that's why I'm basically happy with whatever approach. Just to enable others to proceed with the changes. And just to emphasize that these changes in any feasible way. Yeah, and I can actually see that like you said, putting in the jet means that it is like a first class citizen of the project as a whole that that the terminology that we use is this is that this is our terminology. We can manage the same way that all the other sort of jet level things are design level choice that's project wide and that we can reason over in the same way. I was thinking also about maintainer, you know, if there's so some PR about French language and you're not speaking French. Do I accept or not this PR having this table, make it easy, I think. Yeah, what we could do. Maybe you could just put a recommend the three viewers just to this table as one of the options. Maybe we could standardize it a bit because we had a discussion about official localization partners a while ago. For example, there was a company in Russia, which translated the entire portion to Russian. And we were thinking about making this translation of maintainers more or less official, but it was always somewhere in not on the top of our priority list. But for this particular job, for example, for German translate of a French translation. It's easy because you can just take this call and how many French speakers do we have. Well, you exclude me please but still we have an upright. Yes. We have Google perfect French speakers. Well, not exactly. Google has difficulties with French agendas. I can assure you about that. Yes. Google see me as a male developer. So I have tried on Twitter anyway. So anyway, I think that just putting suggested reviewers here would be the best approach because it's again, it's easy. You just put them and then we can figure out a more complicated process if we ever decide to do so. And they commit to be a review for Russian language if needed and for French. And I stopped sharing because it's time for guava. Yeah, one topic I would like to discuss later is joining conclusive naming initiative as official member. But yeah, I will rather start in the developer mailing list because it's quite important topic. And I think that the participants on this call we already discussed briefly and there was no position at least. So maybe I will start in the developer list right away to save everyone's time.