 So, well, welcome to Valencia. Bienvenidos a Valencia. This presentation is going to be in English. So I will try to do my best. I know that this is the last day of the conference. So I know most of us are very tired. So I will try to make as many as much interactive as possible. So the title for this presentation is Removing Language Barriers for Spanish Speakers Professionals. But the topic applies for any particular language. So I'm going to, in this presentation, I'm going to show what we have been done in multiple areas or efforts that we have it. So coming from a place, from a country where English is not the first language, I know that it's tough for some professionals, especially for students, to start like participating and interacting in all the technologies. So what we have been trying to do is create material, helping all of them, try to provide community days, meetups, all those things in order to help them to be part of this movement. So, well, who I am, I'm Victor Morales. I work for Samsung. I have been working for several open source projects, like OpenStack, OpenNFB, ONAP, and now CNCF. During all these years, I have learned a few things, and most of the open source guidelines applies for all of these projects, and it is not a deception. So my partner in crime, which sadly he couldn't made it, is Israel. Israel is also, well, he works for Red Hat. All his information is here. So it's very approachable, and you can be him in all the possible ways. I know that he would be happy to answer questions and try to help all of these. So, well, I'm going to start this presentation with this quote from Nikita, which is very important. Like, they told multiple times, like, contributing to any open source project or any particular community is not only about, like, coding. So there are multiple ways. Like, you can, like, provide videos. I mentioned, like, participating in the meetups. But something I like to highlight about this quote is helping. And helping has two ways, like, so one of the ways is, like, receiving the help from others, and the other one is providing help. So I'm going to try to cover, like, those directions in the helping. So I'm going to start receiving help. So for receiving help, we have plenty of resources. Like, you can go to Start Overflow. You can check that topic. You can find a lot of answers and questions. So if you want to get deep on all this, you can also go to the projects. You can review the PRs. You can try to find information, review the source code. You can do a lot of all these things. All the meetups, all the community meetings are recorded and posted in the Kubernetes community channel. So most of those resources, given that they have been published, is pretty easily for students or for someone who is not speaking English to access them and take the time to translate them and are using tools like Google Translator to understand what is happening. So another one is like Slack, or participating in the community, like attending the meetings. It's a bit tough because, yeah, you need that level of interaction. And the last link here is one of those which is very interesting. It's the discuss Kubernetes IO, which we have a particular topic where you can ask all these questions in Spanish. In plain Spanish, you can ask them. I have this particular question regarding how to set up Kubernetes, or if I can use this setup or using public limits and things like that. And the idea is, I tried to say here, so there is plenty of materials. And also, it's in Spanish. So I mentioned before, Slack. So at least in Slack and Kubernetes, we have these two channels. So we're our Spanish speakers answering questions and you can reach all of them and ask any question. You don't have to explain all these questions in English. So someone is going to answer. Obviously, this is an open source project. So all the people who are there are volunteers. So just be patient about that. So OK, but now that's one of the things that we are receiving help from others. But the most important thing is, as I mentioned before, these communities is on top of contributors, people from our helping others to participate and respond in answers. So what I'm going to dig now is in the process to contribute. So it's returning back what we have received. So what we use mostly in our presentation is trying to explain how the Kubernetes working from top to bottom. So we start with these different groups. So basically, we have the six, which are the special interest group. So basically, there are multiple organizations working in a common project to a specific topic. And we have the working groups, which are more like a group of discussions. So for example, in my case, I participate in the CNF working group, where basically we discuss things like how to work the best practices for defining other functions, something very interesting for telcos. And also, we have the user groups, which are the place where the topics that doesn't fit on any of the previous ones, most of them are treating it that way in the public way and the communities, where the communities is more like a close groups where they discuss more sensitive topics, which are a little bit of a discretion of the topic. So just to give an example or a picture of the different six working groups that we have it, this is just a sample of them. And those are in different categories, like you can navigate or take a look. So but there is a plenty of them. This is just one sample of those things. So as you can see, the SIG docs is over there. So basically, they are focused in generate documentation and the team, which is part of the translation, belongs to that six. So now that we know the different areas where we can participate and we can contribute, so it's important to mention that there is a contributor level. So obviously, you can, as I mentioned before, so you can generate videos or you can participate in the meetups. So you can be a speaker, all of these things, and all of these participation doesn't require to sign something. But if you want to grow in your involvement in the open source, so there are different stages where you can start, like for example, if you submit your patch, so you need to become a member. So eventually, if you participate more and more, you can start becoming a reviewer, a prover. So the idea is to encourage anyone just to not stay in there like an spectator, like going and taking more responsibilities in that particular area. So, well, how can you start like a, OK, I know that there is a different SIGs and my expertise maybe is in network or in documentation. So what is next? What I have to do? So the first recommendation is just be an spectator, like just try to understand, attend the meetings, maybe just ask you questions. Just try to be there. Like, I mean, it's not expecting. Just invest in your time, just trying to understand what is happening. And probably this is something that is very intimidating, but this community is very welcome. So I provide a few resources. I mean, in this case, it's the list of the SIGs. If you want to code, there are multiple libraries of Kubernetes, so this is a way to participate. And the interesting of this slide is mainly that the last one, which described about the non-code contributions, which is one that I was mentioning before, like documentation. So there is also material, like especially the contribution experience SIG, which has been developed a lot of information about the process and all the best practices and the steps that you have to follow. There are videos regarding that. But one other important thing is mentorship. So it is something that, as a Latin-Americans, maybe we don't have a culture, part of the culture, that there is a mentorship program that you can access to them. You can raise your hand and you can ask for that to participate in this. So if you know about this, it's totally free. And it doesn't require too much to be there. So what else? Again, I mean, we're still in the discovering phase. So in this phase, what is the recommendation? Going in the issues, try to look for something like with that particular label. So for example, help is needed or a first issue. So most of the time, maintainers are trying to require help. So they try to catalog some of the issues with those particular labels in order to be easier for newbies to participate and to contribute. And also, it's a good source for mentors to help mentees to address all these questions. So if you are shy and you don't want to have a mentor or for any case, so that's the only way that you have to do it. And read the docs. So we have docs, we have docs. So there is a lot of documentation. So take your time, read the documentation. They haven't spent a lot of time producing all these documentation. So on the opposite thing, I mean, if you discover that something is missing, maybe it's time to propose a change or submit a particular topic. And documentation is a great way to start early. And now, regarding the different languages. OK, well, we have the documentation. In this particular case, we are talking about how to translate things from English to different languages. So in the particular case for the Kubernetes documentation, that is like from the Slack perspective, we have a lot of channels. So in this case, we are the second one, the Kubernetes docs X. And mainly, the idea of this particular group is to try to translate the previous documentation that I mentioned in Spanish. So we need a lot of people. The documentation is constantly evolving. And also, it's a good way to start getting involved in open source. Because as you're going to see later, the contribution process is pretty much the same, like any other change that we have to submit. So well, this is also another few links that we have it. So we have PRs. We have a Slack channel. And so this is more like a call for action to participate in all of these things. So there are four things that you have to keep in mind when you are going to try to participate in the translation. So the first one is very obviously, because you have to sign the CLI. So the CLI, there are basically two types. You have to sign as an individual or as a part of the compression. So don't feel overwhelmed. It's just part of the process. It's not protecting the source code. You can read all the CLI. It's just one step. The process is quite simple. So the other thing is like, especially in the Kubernetes documentation website, you require at least to understand a little bit Hugo. Hugo is a platform that is used to generate the HTML. So the documentation is written in Markdown. So Hugo is the tool that we are using to deploy the website. So this is just to know in the tooling. It's not mandatory to know Hugo or to deploy it or to use it. But it's good to have it. It's good to have at least that idea. Obviously, a little bit understanding about Git and GitHub. So it's very well to have it. And you will require to have at least a GitHub account. So without all of this, it's not possible. And the other tool that I want to also mention is Netify. It's not important that you know or to understand what is happening. But it's good to know that it is used during the process. And you're going to see the impact that has in all this contribution. So well, let's go through the steps to contribute to the documentation. So the first thing that you have to do is most of the GitHub projects. So you have to do a fork. So what a fork means is just basically creating a copy from the main project into your own account. So in this case, what we are going to fork is the Kubernetes website. So we are creating a copy in our own account. And this diagram is showing the workflow that most of us or maybe you haven't seen before. So basically, what you have to do, you have to clone your changes in your local computer. So in this case, a website, you clone it locally. So you start working the translation. I mean, it doesn't care if you start like using translation tools, as long as you read it and you make sure that everything is covered. So you have to create a branch locally, submit or create your commit and your own branch. Push your branch in your fork or copy of the project. And from there, you have to pull requests. So usually, that's the workflow that you have to do. What we have created is we have created an issue in order to avoid two people working the same concept or the same page. So that's the way that we used to coordinate efforts. So before doing all these things, I encourage you to raise your hand and say, well, I want to work in this particular involves or in storage on any particular topic. In that way, we are going to make sure that no one is translating exactly the same website. So after you made the pull request, feedback is started, especially for reviewers. So any feedback that you receive, you have to go through the same process. So maybe create a new commit in your copy, submit to your own account. As long as you keep the PR open, all these changes are going to be reflected. So don't frustrate because we are humans. We take time to review things. And obviously, everybody has their own priorities and a schedule. So don't rush and don't try to push reviewers to push your change to remain. So again, pretty much explain the process. This is just using the command line if you prefer. So as you can see, in this case, Rael was doing a clone from the website repo. So as you notice here, Rael is doing a clone from his own copy. So in that way, the pointer that you have to originate is his own account. So he started doing the translation. He created a branch. In this case, he's creating a local branch. He started working, probably translated something, normal, regular development process changes, add those changes, make a commit. There are multiple best practices for doing a commit message, well-known. So I'm also encouraged to take a look. So once that you have all these things, this is something personal. I prefer to test things locally. In this case, you can install Ugo. If you don't have it, I mentioned before Ugo. Ugo is a tool for deploying. So all these instructions are just a way to test all these things. I mean, I say that it is not mandatory to do all these things, but it is better if you make sure that everything is working. So if Ugo is not installed it, you can install it. And by the way, there are some make instructions. So we have tried to simplify the process to deploy things locally. So once that you deploy things, you can verify that your translation, the portion that you have translated, it is there. Everything is OK, so far so good. So you can push your changes to your own branch and your repo. And from there, you create the pull request. So explain it twice. So this is the most common error that you can see, especially for first contributors. So what you mean is that you haven't signed the CLA. So it's very simple. So you only have to click one click. So that is going to redirect to the website. So from that website, you have to read the CLA. I mentioned two types, like individual contributor or from corporation. Once that everything is gone, once that you have signed the CLA, the CI process is going to trigger. So and the most important thing is here is regarding the last step, regarding Netify. So why is this important? Because well, before going that, most of the reviewers are not going to take a look at your change if everything is green. So make sure that everything is passing. Once it is passing, the reviewers are going to start taking a look because it's the one way to avoid wasting time. So the last step is regarding Netify. So with Netify, what you can do is you can check or take a look of the preview of your change in a public accessible website. So again, it's just making sure that all the changes are there, everything is working as expected. And the process started. So as a reviewers, we check the PR, we comment, we make suggestions. So back and forth, changes. The last thing, we put multiple labels. In this case, a GTM, which means it looks good to me. So usually we require multiple reviewers to take a look and put those labels. So once that everything is good, we have multiple people who has reviewed your change. It is approved. The PR is approved, which means it's triggering more processes. And finally, it's merged, which means your change is going to be part of the Kubernetes main branch. And obviously, those changes are going to be deployed in production. So your changes, what you have translated, is going to be as part of the main website. So the last thing that I want to just talk about is an organization initiative that we have it. So this is more oriented to CNCF. So basically, we have two resources, or in this case, the Slack, where you can access to or connect contacts to us. And the Carolina. Our weekly meetings are in Tuesdays. So it's 1530 UTC. And we have two main other initiatives or documents that we are trying to translate. The first one is regarding security. In this case, Carol is leading this effort. She is proposing. And this is not following the previous process. This is mainly a Google Docs web document where people are putting the translation and saying all these things. And the other one is a recent one. The CNCF has a glossary. So in this glossary, basically, we have multiple terms where we try to explain with single words the several concepts like DevOps or containers or things like that. So this is also a good project or a good way to start contributing and participate in the translation. So you also provide the links for this. In case that you want to contribute, any contribution is welcome. So and I guess all of this is done. So thanks. So any question? Any? So it's there. Thank you. English or Spanish? I think it's going to be in English. English? OK. So in your opinion, to be a good contributor, what is the time commitment for it? We have families. We have jobs. Well, yeah, it's kind of tricky question. So probably my suggestion is make sure that whatever that is your cadence or your piece, you can keep it. Because I notice that a lot of energy people try to contribute the first few weeks. They're very happy with the contribution. But this is not a race. It's a marathon. So find that cadence that you have it. Maybe choose pick one day. Maybe Fridays, Mondays, whatever that works for you. And just book that particular day. So the important thing here is like, because you have to demonstrate your commitment. So no one in any open source community wants to see someone who throws the source code and leave it. Even if the code is amazing, so what they want to see is commitment. So if something is broken, who is going to fix it? So that's probably my recommendation. Just choose whatever that works for you. Think about a roadmap from two years or something like that. So you would say like two hours a week, one full day a week? Yeah, probably. Maybe one or two hours per day, you can start with that one. So as long as you can see, maybe you can increase the time and say, well, maybe I can spend more time on this. And also the idea of documentation is, as I said before, this is a very low entry level. So this opens the opportunity for once that you manage all these things, like starting to contribute to the client or the different components are going to be very easy. Because at least you manage the basics. Thank you. So of course, I encourage you to join to the channel, participate in this and try to at least work together as a community. We struggle with trying to find volunteers. So it's always like a welcome to have extra hands on this. And I will be around for any other thing. So thank you.