 Okay, hi everyone. Hi dear colleagues. My name is Sergei and I'm working on Linux system roles. And in modern world, diversity, equity and inclusion became a main topic and a focus and because it's important for all of us to feel comfortable on the projects that we work on and the projects that we use and we participate in. And one of the parts of these is conscious language which is about using words that are rather inclusive rather than exclusive. And in Linux system roles, we started using a tool that is called walk to detect language that is not inclusive in our code. So today we'll cover, first of all, why this initiative is important and then we'll switch to technical part about the walk to itself and its features about the GitHub action that exists there with walk and then about some caveats that we had working with walk and how we worked around them. And yeah, after this we'll have some Q&A section. So software often carries, often uses some words that carry a great deal of emotional and historical baggage. And to be truly inclusive and welcoming, we should try to avoid the use of words that can carry these unintended second meanings just to welcome all the participants and just to not limit the number of participants that we might have. So that's the first reason and the second reason is for those who use English as their second language, it may be problematic to translate those idioms. And now let's move to the walk tool. So here I described the pictures that it has, so it finds non-inclusive terms in your code in file names and in the content of files themselves. It also suggests alternatives that you may use and it has some configuration that you can apply, for example, to identify the words that you want to mark as warnings, words that you want to mark as errors and also you can choose what paths you want to search on. So yeah, here you can see the example of the GitHub action that exists there that enables you to run walk on every PR in your GitHub repo to identify if this PR does not introduce any non-inclusive terms in it. So it's pretty simple. And here I have a slide demonstrating how this will work. So it sees that there is a non-inclusive term in your code and it has this pretty feature that prints the exact place where this occurs and also prints the terms that you can use instead, if you wish. And in this case, this is marked not as an error, but as a warning. And as for the caveats, that's the reason these two. So in my project, we needed to mark some words as errors to strictly fail on them and some words as warnings. And currently the tool fails both on warning and errors and we needed to change this. So we made this change to the code and submitted this PR, but unfortunately the second issue is that there is a lack of attention from the developer, from the initial developer of this tool. So hopefully the developers will return and continue the work, but for now we did the following. We created a clone, kind of forked the project into our local repose and just created a custom action instead of the official one. And here how it looks, you can see that we are pointing to also to our configuration file that we also customized for our needs. And instead of the official action, we're using just the path where we copied it to. And yeah, that's pretty much it for myself. And please, if you have any questions, yes please. Sorry, could you repeat, I think I didn't catch it. Yeah, so you're probably asking about GitHub actions. GitHub actions is an environment that GitHub provides where you can use GitHub resources, virtual machines and containers to run any test on your repository. So you can configure it to automatically run anything on special triggers. So for example, in our case, we are running the stool on every PR to check the content. Yeah, of course, yeah, you can also run work locally and yeah, customize everything and just use it locally as well. Just continue and I will get to you. Is there a plan to make? Yeah, actually the fork, it's pretty, we just, yeah, I'm repeating the question. So the question was if we can make the fork available to everyone and the change that we did, it is currently publicly available in our GitHub and it's actually pretty small and it's not actually the full fork but we just copied the code to our repo. So officially, it's not a fork. And yeah, so in the next slide, by the way, I have a reference section where I'm, yeah, I'm linking to this fork that we did and also linking to some other things that I talked about today. Yes, thank you. Please. Just a question. When you mentioned that the work action, actually the text includes the words but what if those words are part of the documentation of specific tooling that can only change and is there like a way to ignore, because there is this but we cannot change it because of this tool that's how it provides it. Yeah, so to repeat the question for the audience, is it possible to ignore work on some particular lines because sometimes, and this is the case with our project as well, we're working on many subsystems that just use the non-inclusive terms and we cannot use them in our project because we're just automating what is there already. So yeah, so first of all, in our configuration file we marked some oftenly used terms as warnings and did this change to not fail on them and also you can ignore separate files in the config file or also in the file you can ignore a separate line by appensing a comment above it or to the right of it to say walk, I think it's walk, ignore and the name of the rule that you are ignoring. So yeah, it is supported. Yes, please. So optionality of the code, right? And I'm guessing that remains to be just hand-picked manually but by whoever uses it. It shouldn't be changed like a copy and replace, right? So you need to check every instance like that. And is there any possible way around that or is that just how it works? Well, yeah, that's the work. Yeah, the question is about that sometimes again, you have terms that you cannot change because they are part of some other underlying project that you don't have like authority to interrupt and what are the ways around it? And yeah, so in our case, we needed to do this work and to just run walk on every repository that we do support. And we like about 20 of them. And of course, some of the terms could be replaced because we are using them only in the repo. And some of the terms come from the underlying project. Some, for example, the name of the main database is a master database in Microsoft SQL Server and Microsoft IDAL that they are going to change it in for civil future. So yeah, that's something that we need to live with and yeah, in this case, we just need to ignore this word either in the config file or on the line itself. Any more questions, please? Okay, if not, thanks a lot for your attention. Again, I think you will get the link to the slides and the slides I have the reference section where you can click through the things I talked about and have some look at them. Thanks a lot.