 I'll touch base with our next speaker so we can get, we can continue with the presentation. Our next speaker is some touchy on your query. I think a bit, a story before she starts her session, I was at KubeCon Barcelona back in 2019. And a number of us Nigerians and a couple of Africans, you know, we rarely recognize ourselves as Africans anywhere we go, we met and was like trying to find other people that are at the event and doing awesome things within the ecosystem and conversations started around how we can support each other within the ecosystem and also connect with other people. So when I joined the Kubernetes SIG meeting and I saw someone presenting, I looked at the name, some touchy, okay. This name sounds Nigerian. Immediately I went to look up on Twitter and I was like, wow. Now, now I perceive it is great things and presenting in a SIG meeting. The SIG is special interest group within the Kubernetes ecosystem where people contribute to the main Kubernetes project. And recently I learned she has joined with works which was like, wow, that is awesome. So some touchy is also a contributor to the Kubernetes project. She will be sharing with us how you also can contribute to Kubernetes. Over to you, some touchy. Yeah, awesome. Okay. Yeah, I hope everyone can hear me. Good morning. Really excited to be talking today. I see like a lot of people are here and definitely you... Yeah, I think we lost some touchy's video and audio, but we can see your screen if you can unmute and share a video again. Yeah, okay, okay. Awesome. Yeah, okay. So I'll just go again. Touchy, I hope everyone can hear me. My name is Somtouchy Onyukuri. I'm a developer experience at Bivorks. I work on their open source projects there and you can always reach out to me at Twitter and GitHub at SomtouchyMR. And this talk is going to be around contributing to Kubernetes. At the end of this talk, I hope at least even if it's just one person, that gets to contribute to Kubernetes. Like that would be just awesome. So basically I'm trying to push you guys to contribute to open source and in particular Kubernetes. And yeah, I'm just going to work you through the process and hopefully make it a bit easier for you to get started with that. I'm going to try not to talk too much and try to leave a lot of time for questions at the end. So yeah, I mean, sorry, let me present this. Okay. So this is basically an outline of the talk. I'm going to tell you why and how to contribute to Kubernetes, different groups in Kubernetes that make it work, how to select your first issue, how to make your first pull requests, different mentoring programs and also how to grow as a contributor in Kubernetes. I think all these are like important parts of how you can work yourself up to contributing to Kubernetes. So first off, I know a lot of people, I heard Bakari saying what Kubernetes is. So hopefully most people here at least just have a general idea of what Kubernetes is in short. It is used for managing containers, it's called a container orchestration framework or platform. But I'm not here to talk so much about Kubernetes or about contributing to it. So I'm going to tell you why. So I don't know if you know this ma'am here, it's basically something Unicode developer sees a new day, another opportunity to be world-class. So I think a major reason I would give you to contribute to Kubernetes is because you gained a world-class experience. There are a lot of experience developers on Kubernetes. You have Google Ads, you have people from AWS, Microsoft, there are a lot of big companies really investing engineers to contribute to Kubernetes. And when you start contributing to Kubernetes, you one way or the other, you have the opportunity to work with these people, they review your call requests and not just like Unicode basis, right? You get to collaborate with people across different time zones, right? You will learn how to communicate and how to collaborate with people who are not even around you. The commit is also very active. The project has over some six case stars on GitHub. It's very active project. They are like in the main repository, they are over a thousand request open like right now. There are a lot of people really focused on Kubernetes, a lot of companies. You get to, over time as you contribute to Kubernetes, you get to meet people, you get to build your network outside where you are. So I really think that contributing to Kubernetes has really helped me. It will help anyone who actually says, oh, I want to contribute to this project, I want to make changes and I want to be active. I think if you try to contribute to Kubernetes, yeah, you definitely get more experience. And also a lot of companies hire around like Kubernetes, the infrastructure, you understand it better. And also there are like a lot of job opportunities to around Kubernetes. And you saying that, oh, I have contributed to Kubernetes, also looks great on your portfolio. So I'll start out by saying that it's okay if you're a little confused or scared when you're starting out to contribute to Kubernetes. Frankly, it will be weird if you're wearing it because Kubernetes is a large project. There are a lot of people, sometimes you just look at it and you're like, you don't know where to start. So I think that was basically me when I started. I was like, whoa, this project is like a lot. Like it's been there for a long time and you have like people constantly contributing to it, change this stuff. And you're like, can I actually make a change here? Do you get, but like that's okay. I think that's our initial reaction when we are coming into something that is new, when we're stepping out of like what we're used to, when we're stepping out of our comfort zone. So I think even if you feel scared, even if you feel confused, that's not a reason not to do it. So I'm just basically here to tell you that if you're feeling scared, if you're feeling confused, that's fine. You're not the first, you're not alone in that. I contribute to Kubernetes. And even now, sometimes I'm trying to contribute to like a new part of Kubernetes. And I'm like, oh, I'm not sure what I'm doing. But I think you can actually work through the confusion and make a reasonable pull request. Like the thing is, if you make a pull request there, people review your pull request and they won't let you just do anyhow. They will actually review it and say, okay, you didn't do this right. Or this is actually not where it's supposed to be. You have like some amount of guidance from the community. So I think you should take on some comforts and that. So there are different ways to contribute to Kubernetes. It doesn't have to be code. I know there are a lot of programmers on here, but even if you don't write code, like that's okay. Kubernetes has a lot of documentation. If you're a technical writer or even if you aren't or you just think like, okay, I don't write code, but I think I might like to like write stuff. Their documentation is actually very extensive. They have like a blog post. They have like blog posts. They have like a full whole website dedicated to Kubernetes because there are a lot of moving parts. So if you're good with writing or you could just try it out. One thing I've learned is, you know, if you're just looking at an open source project and you feel like you're reading through the documentation and something is unclear and you think you can make it clearer. Like just open a pull request for it. It doesn't matter. Like if you're not, if you don't think you're a fully qualified technical writer. So even if you do design, we have the CGUI which is for the Kubernetes dashboard where it's like a dashboard to display some insights into what's going on in your cluster. You could also join in. Also, it's a very large community. There's always efforts for managing people or managing projects, managing the community. So if you think you project, you are leaning towards project management or community management. Like that's still great. There's definitely a space for you. There's like the Kubernetes release theme which sort of like coordinates and Kubernetes releases that happen like four times every year. And, you know, it takes a lot of people. There's the release team is basically people managing like, oh, is this pull request going to get in before, you know, the release is ready? Doesn't need documentation. Checking in with people who are supposed to submit pull request for these changes. So yeah, all those things are like project and community management. So if that's where you feel you can weigh in, like that's totally great. And also the main Kubernetes repository is written in Go. And people have this mistaken mindset that you have to know Go to contribute to Kubernetes as well. I feel Go is definitely a plus. If you write something like Python, Java, we have client libraries for Kubernetes that are written in those languages. The Kubernetes website too is basically HTML or CSS. You can get started from there. There are a lot of testing that goes on, a lot of testing that goes on in Kubernetes. So you could also weigh in there. So yeah, I hope you're able. There are also marketing initiatives within the Kubernetes communities. It's a very large community, you know, they have social media, like there are so many different ways to weigh in and just joining in the community, even if you don't code, it's still going to be very valuable for you. So there are different groups in Kubernetes. You have the special interest groups which are focused on a particular area in Kubernetes. Cube CTL is the command line tool for interacting with Kubernetes API. And the CIG, the special interest group CLI, is focused on like that and other CLI tools that built around Kubernetes. You have CIG Contributex, which is focused on contributor experience. Kubernetes is a very welcoming community. They put in some efforts, a lot of efforts actually to make as in contributing to Kubernetes a better experience. So there's a whole group that cater to that, just trying to get people to contribute, trying to make sure it's like a smooth experience. So there's also something called working groups. These are not the only groups in Kubernetes, but these are probably the most relevant ones. Working groups are like less, they are more temporary and they cut across multiple CIGs. So something like the multi-tenancy working group is cut across CIG nodes, CIG storage and like a bunch of other ones. So yeah, you can find out more about each CIG on the Kubernetes community repository. If you can, I hope my screen is clear enough, but I can see that there's a lot of, like there are different folders for each CIG, each of them sort of explaining what the CIG is about, how you can contribute to them and different stuff like that. So it also has the contributors guide, which is also, if you're just starting out, you should definitely read that. So this repository is basically like a treasure for someone who wants to contribute because you can't really get a lot of information. You can read up on the different CIGs, the different working groups. UG means user groups. So yeah, you can definitely just take a look at these repos if you maybe spend some time trying to find out like what the different stuff is about. And you should get involved with Kubernetes. So first, you should probably be on the Slack channel. You can invite yourself at the URL displayed on the screen, slag.khs.iu. You should check out some CIGs, try to find one that is aligned with something you're interested in or something that is related to your job or just pick randomly if you don't know. You're not tied to a CIG. You can basically try out different CIGs to find out, oh, okay, these are probably the ones like I like what they do and I feel like I can contribute to them. You want to join their mailing lists. You want to join their Slack channel. Each CIG has like a Slack channel where they discuss like issues focused on the area that they handle. So you should also try and join their meetings which they try to make it at a very comfortable time for like everybody. So if you can, it might be late for you, it might not. So if you can't join their meeting times, ask questions, introduce yourself. Most of them are welcoming contributors. Most of them are actually excited to have people join them and be interested in what they do. So I'll definitely encourage you to do that. Then to make your first pull request, you have to pick an issue. So you can filter if you're unable to pick a CIG. I think when I first started, I was not able to decide on which CIG to contribute to. It was like still all new to me. But some people sort of like they know or it just caught their eye. So I started by filtering for good first issues and hope on that issues and picking those ops. Those were like low-hanging fruits. I could easily get started with. So you can filter the main repository for it. If you have decided on a CIG, it's most likely they have their own repository. So you can also go there. It doesn't have to be the main Kubernetes repository that you're contributing to. And even on the main Kubernetes repository, each issue is labeled with the CIG that is consigned with it. So you can actually filter by the CIG that you want to. You can also ask the CIG, like, okay, you can join the channel, introduce yourself. Like, oh, I'm a new contributor. I'm looking to join a CIG. I'm looking to pick one or two issues. You kind of just ask, like, just communicates. You probably should not do that on the general channel. But the CIG channels are actually good ways to also find out what's important to the CIG. And those are probably the issues that they try to get contributors for. Then you could read through the Kubernetes documentation. And if you find small typos, comments that, you know, you could actually, it could be as simple as that. Your first pull request doesn't have to be large. It doesn't have to be this massive change. Most times, you know, you want to keep it small, especially when you're starting on, because you probably don't understand the whole system. So you probably want to start small. So updating, if you see, if you're reading through the documentation and you're like, oh, this could be explained better or that's a typo. You can't like, you can't just make a pull request for that and as simple as that, your first pull request is in and then you grow from there. So there's a pull request process. You have to get your pull request margin. You have to sign the contributor license agreement. It's not difficult to do. It's literally just like a couple of clicks. It's not an extremely complicated process. It's just, you just sign it. Then you need a Kubernetes member to apply the okay to test label on your, you need a Kubernetes member to apply the okay to test label on your pull request. So it's basically saying like, okay, there cause a lot of tests run for each pull request to validate it just to verify your changes. So it's like saying, okay, this pull request is like, you can run the test on it. Most of these labels, they're applied by the robot. So when a member comments, something like this slash okay to test on your pull request, it means, okay, the robots now act on that. It applies the label and then, you know, allows the test to run. So there's also something called LGTM, which means looks good to me is applied by a reviewer, someone who has reviewed your changes. Probably the person has made some comments. You've responded to the changes and is like, okay, a pull request is good. Like it looks good. I think you've done it on okay job on this. Then the slash approve is saying, oh, it can get meshed now. So it says, okay, basically means your work is done. Maybe you have to rebase your pull request and squash your comments, but it means, okay, like your job is almost done, you're almost there. And then sometimes because of how big Kubernetes is, it might be, you might make a pull request and not get some traction on it. And that's okay. There's something called a PR review channel for, it's called PR review. So it's basically to sort of like get more eyes on your pull request. So you can just like say, oh, I have this pull request. Can someone take a look? And also the robot tries to apply the correct seek that your changes associated with because they are going to be the ones to review it and approve it. So you can just join the seek and say, oh, I have this request open. Is this something you guys want? Can someone take a look? And then as a last resort, you can also ping the person who opened the issue if you are making a pull request for an issue. You can, okay, just ping the owner and say, okay, you made this issue and I just opened the pull request for it. And there's been like no traction on it so far. But I also want to say that when you ping people on Slack, they might be in different time zones. So if you don't get a reply immediately, that's absolutely fine. You should probably just give it some time. The person might not be available. The person might be on vacation. Or yeah, I'm just saying like don't feel discouraged if you don't get an immediate response from people and try to communicate in the channels more than like DMs or less if you guys haven't communicated for some time. Yeah, so if you don't get a response immediately, that's fine. The person might be in a different time zone. Maybe the person's gonna sleep in. So yeah, just apply some patience and definitely you will eventually get your pull request merged. So I want to spend some time talking about the contributor ladder. So once you make your first pull request, you're basically a contributor to Kubernetes. Oh, I forgot to put some diagram. But yeah, you're a contributor to Kubernetes. Then after some time, if you are active and you make more pull requests, if you join the release team and become a shadow, which is sort of someone that shadows the release leads and helps out with other tasks, such active involvement with the community actually pushes you to become a member. It helps you become a member. For you to become a member, you need two community members to okay you, sort of. So that will be tough if you're actually being active. You actually get to meet people as you make pull requests, join meetings, join the SIG. So definitely one or two people, it shouldn't be too difficult to find two people from two different companies that will say, okay, I think she's doing a great job. She should be a member. Then the next step is your reviewer means you get to review other people's pull requests and apply the LGTM label on different pull requests. So each repo has different people that are reviewers and approvals. It's not across the whole organization. It's more like scoped to a particular repository. So yeah, if you're active in a SIG and you're making a lot of changes and you're really knowledgeable about what's going on there, you can actually just request, oh, I want to be a reviewer. And if the leads of the SIG can see your contribution, they will probably make you one. The next step is you can be an approver where you actually get to say, okay, this request looks good enough to be merged in the repository. There's also like co-chairs of communities, there are SIG leads. So yeah, I think it's a great way, you can definitely see yourself progressing. And I just want to say that you don't have to pressure yourself. This is just the ladder, but it's not like you can't like, for me, I've been contributing to Kubernetes for like over a year, I'm a member. I'm not a reviewer in any repository yet. It's just like you can't do it in your own time. There's no pressure and you don't have to say, okay, this week I want to be a reviewer, next week I want to be an approver. It's not like you cannot go post. It's basically just something that happens over time as you become more and more active in the Kubernetes communities. So yeah, I'm just going to go over that again. It's good to progress your contributions in the community. You should not just do it because you want to be a reviewer, you want to be an approver. I think that's a wrong motivation. Just be active, care about the parts that you're doing. And I think these things just come with time. So yeah. I want to round off by talking about mentorship programs for different people. So there is Google Summer of Code. Google Summer of Code is how personally I stay contributing to Kubernetes. I wanted to apply to this Kubernetes project under the CNCF. So I'll definitely encourage students to apply for Google Summer of Code. It was like a great experience for me all around. One of my mentors was a Googler. The other one worked at Weaveworks. We are working now. So I think if you're a student, you should definitely apply. But I want to also add in that the applications are closed right now, I think. But if you start contributing to Kubernetes now and you try to grow your contributions now, you get a very nice margin over other applicants because you're familiar with what's going on. So if you can start contributing now, don't wait till next year when the new application starts. So if you can start contributing now, please do so. And also for the benefit of learning and growing your skills, there are other ones. There's the LFX Mentorship. There's Outreachy. There's Google Season of Dogs for people who are technical writers. So just check in on any of them. There's a repository where you can see the difference mentoring programs that are linked there. So yeah, I think coming on our mentorship program is also great. You can also contribute outside of this mentorship program. It doesn't have to be. But some of them are paid. And I think it can be quite encouraging just to be paid for contributing to open source. It could be a great way to start off. So I want to summarize by saying you can become a contributor to Kubernetes. It's not that difficult. I know it could be very challenging at first, but it gets easier. You pick an issue. You work towards it. You try and communicate with people. You join a CIG and you can become an active contributor. So I'm going to end now. You should take a look at the contributing guide that the contributing members have put together, which is very, very helpful for new contributors. There's also a contributor sheet where you can get a lot of insights to what just goes on as a contributor. Yeah, so I've linked both of them. I think these are very active and very helpful links. And you should definitely check them out. And you can also reach out to me among Kubernetes Slack, Twitter, GitHub, some touchy, yeah, just connect. And if you need anything, just reach out. So I'm excited to take in your questions now. Can anybody hear me? Yes, I can hear you. OK, stop sharing. We don't currently have any questions in the chat. Let me check the chat if we have questions. OK, we don't have any questions in the chat yet. Awesome presentation. One question I would like to ask is, sometimes when you want to contribute to Kubernetes, it has a lot of paths when you want to get started. Sometimes you have no idea, OK, where should I start from? Is it docs? Is it the home charts? Is it which one? So what advice will you have for someone that, OK, it just goes to the project and wants to start? Where exactly should they start from? You can start from the Kubernetes main repository. That's the call the K slash K. That's kubaneses.github.com slash kubaneses slash kubaneses. You try and filter for good first issues, help wanted issues. That's you can just basically kick it off like that. If you are coming from maybe you build a lot of CLI tools, then you should check out CCLI, since that would be more aligned with your interests. So you'll probably get to work on the Kube-CTL command line tool. If you're writing a lot of documentation, you should definitely join CIG docs. Ask them, oh, I'm a new contributor. I'm looking to join you guys. You know, where can I get started? Yeah, and if you don't know what else to do, then just join the CIG Contributex. They also try to make it easy for new contributors to get started. Like they have a lot of like very new, like it's easy to make progress to that community repo. They have like just like docs and stuff like that. So I think as a last resort, you can actually just join Contributex and say, okay, I want to be a contributor. Okay, awesome. So that's Contributex is like, is Contributex like where someone that doesn't have any experience with code or anything and doesn't even have an idea where to start? Contributex is the best place for them to start. Yeah, I think that's okay. You can join them cause they are basically around making the contributor experience easier and smooth. So you probably get some help and direction from them. Okay, awesome. We have a question for Sebastian who is watching from YouTube. He says, what would be the future you would want to see in the next Kubernetes release? Uh, features. Yeah, like cause I've been every, they're like a couple of release features that I was looking for to get merged, but it didn't because the people that are working on them probably didn't have the bandwidth to get them in. But basically, if you go to, if you're curious, if you're more curious about, about different like feature proposal, there's something called Kubernetes enhancements, which are basically like proposal people make for like new features in Kubernetes. Let me get the link. Sorry, second. So yeah, let me see. So there's this. Okay, let me call the link. Okay. I don't know, I'll just paste it in this chat. Yeah. I'll send it back and add it to the chat. So those are the enhancements. You can like check the features there. Like read up probably comes, most times it comes to like extensive documentation of what's new features, the ones added or what's enhanced. For me, there's this Qubes CTL debug feature that I'm looking forward to. It's been open for some time, but I'm looking forward to it getting like some traction in community and also most of, also some features are on cluster add-ons, but it's not related to the main Kubernetes repository. I hope that answers your question. Yeah, I think he just responded back. He said, yeah, he gets it, but okay, yeah. I think he added a comment again, based on the last thing you mentioned. At first he asked, yeah, but is there a feature that you would love to see, even if it doesn't exist yet? But when you mentioned Qubes CTL debug, I think he kind of got it. So we don't have any other questions on YouTube chat. I can see one question on here. So if you're interested in documentation, please join C-Docs. I think it's a very active seek. They do stuff across different documentation, like a blog post and stuff like that. So if you join C-Docs, you definitely get some guidance on how to get started. So I would say what you should do now is join Slack and join C-Docs and introduce yourself. You can also take a look at the Kubernetes' website repo and see if there are any open documentation, which is the only newly built documentation so that people know. Let me see. This is the website repo. So but C-Docs is definitely the way to go for people who are interested in contributing. Yeah, okay. Someone just posted a link. So yeah, I just want to reinforce that it doesn't have to be code. Even if you don't write code, that's okay. There are definitely different ways that you can contribute in the Kubernetes' community. Awesome. Yeah, I think we've reached the time limit for the session. Thank you very much for the awesome presentation, Sumtochi. And please, use your Twitter handle. I think people should be able to know you and learn from your posts online. Yeah, at Sumtochi, I'm off. Okay, if you can drop it in the chat, we'll add it on the... Okay, I'll do that. Awesome. Thank you and... Thank you. Bye.