 Okay, we're going to get started. I'd like to thank everyone for joining us today. Welcome to today's CNCF webinar. You can be a Kubernetes contributor too. I'm Jerry Fallon, and I will be moderating today's webinar. We'd like to welcome our presenter today, Jeremy L. Morris, software engineer at Digital Ocean. Just a few housekeeping items before we get started. During the webinar, you are not able to talk as an attendee. There's a Q&A box at the bottom of your screen, so please feel free to drop your questions in there and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or the questions that are in violation of the Code of Conduct. Please be respectful of all your fellow participants and presenters. And please also note that the recording and slides will be posted later today to the CNCF webinar page at cncf.io slash webinars. And with that, I'll hand it over to Jeremy for today's presentation. Everyone, thank you for coming to today's webinar. My name is Jeremy Morris. I'm a software engineer at Digital Ocean. I currently work on the team that maintains Digital Oceans managed Kubernetes solution. I also contribute to Kubernetes and I'm a co-maintainer of a few sub-projects within Kubernetes, Digital Ocean cluster API provider and Digital Oceans cluster autoscaler. I'm also currently a shadow on the Enhancements team for the Kubernetes 1.20 release. And today I hope to show you how you can be a contributor too. So why should you contribute? From my first commitment, which my first contribution, which was about two years ago at this point, I feel like the experience that I've gotten in terms of developing my skills as a software engineer has increased dramatically since then. I've also had the opportunity to work on a complex code base, experience working with distributed teams in different time zones. I also got some experience with project management and planning. For example, as a shadow, my responsibility is tracking down and following up on the completion of Kubernetes enhancement proposals and making sure they get into the 1.20 milestone. All of this is real experience that can translate to a real software engineering job. I think the experience that you get from contributing to Kubernetes can definitely help your personal and your career growth. Another reason is, of course, it's mutually beneficial. Not only does Kubernetes get a lot of new contributors that can help push the project along, but you're also getting the exposure to the community and all the brilliant engineers that work on Kubernetes. You also get to benefit from developing your collaboration and teamwork skills because at the end of the day, when you work on an open source project, you have to learn how to collaborate to be effective. Another reason is that there's tons of work, but not enough contributors. When you try to build software that is supposed to solve a diverse set of problems for diverse groups of people, Kubernetes is used throughout the world. It only makes sense that the contributors are also coming from a diverse background. You want those different perspectives, so it's in Kubernetes benefit to include more people and be more inclusive. There's also a lot of problems to solve. I've listed a few links here, and these are just the projects that I've contributed to myself, contributed to myself, and people that might not know this, but there's Kubernetes organization within GitHub, but within that, there's a bunch of projects, not just Kubernetes core, which I'm sure everyone here might be familiar with, but there's also like Test Infra, Enhancements, the website for Kubernetes.io, also the sub-project that I co-maintained, which is a part of Kubernetes 6. Another organization, which exists kind of alongside Kubernetes, relates to projects that have to do with the different six. So there's a lot of work that's available for people to work on, and I'm sure if you're interested in contributing to Kubernetes, you can definitely find something that you're interested in. So how do you get started contributing as a beginner? I feel like when people want to contribute to Kubernetes, there's this kind of like perceived high barrier of entry. There's so much work, and it's so big, you're not sure exactly where to start. My recommendation to start out with, and I found this useful myself, is to find an area of Kubernetes that you're interested in. There's this concept of SIGS, which is a special interest group, and different parts of Kubernetes will have a SIG that kind of governs that sub-project or area. So for example, there's SIG networking, SIG testing, SIG cloud provider. You kind of just have to narrow down what interests you, and just follow up with the SIG and make sure you get acquainted with it. You can do this by joining the Slack channel. Every SIG has a corresponding Slack channel. Try to attend some of the meetings, and just try to be a part of those discussions so you can figure out what exactly it is you can work on. So at the end of the day, SIGs love new contributors because there's a lot of work that needs to be done, and if you let them know that you're interested in contributing, they will definitely find work for you. Another thing that I found useful is, once you find out a SIG that you're interested in, or even if you don't, you can take advantage of GitHub's label filter, and what a lot of the Kubernetes maintainers would do is they'll label good first issues for issues that are ready to be picked up by a new contributor or beginner. So simply filtering on good first issues, you've already narrowed it down to a bunch of issues that you can get started on, or people will be willing to help you out with. And then another way to find issues that I kind of found out recently is testgrid.case.io, and this is a way that they track the automatic tests that are run against the PRs, and you can get a good view of what's flaky in terms of testing, and then you can either find an issue that's already tracking it or you can make an issue yourself if there isn't one currently tracking those flaky tests, and then you can hunt down whatever is causing that and solve it. That's not the easiest thing to do, in my opinion, to find issues that way, but it's possible. If you're not able to find anything in the existing issues tab, you can always look at the flaky tests because there's quite a bit of them, but there's definitely an active effort to hunt down those flaky tests. So if you can help contribute to that, people will be really greatly appreciate that. Another thing is it's important to communicate. So from the start when you're interested in contributing, communicate that. If you join a SIG channel and just let them know politely that, hey, I'm a new contributor, I like to get started. Is there any work that you can point me to to get started on? To even once you get assigned a task, communicating the issues you're having or maybe your availability has changed since you last accepted to take on that issue and you're not able to work on it as much anymore. I think it's just important to over communicate because no one's going to judge you for the time that you put into the work that you're doing or if you're not able to solve something because everyone has to start somewhere and Kubernetes is really complex. But people will really appreciate if you just communicate anything that's going on with the ticket because it's a team effort. So you want to just work together and get it built in relationships. I don't think I could have gotten as far as I have in terms of now being a Kubernetes member and the co-maintainers and subprojects without actually building relationships. A lot of people have helped me along the way in terms of finding issues, even the opportunity to co-maintain a subproject that was brought to me. So things like that will pop up more and more as you build rapport with different members. Another thing that I got to take advantage of was the Linux Foundation's Diversity Scholarship. People might not know about this, but the Linux Foundation has a bunch of scholarships for different conferences. And KubeCon in 2017, this is what you see pictured here. That's a conference that I got to go to because of the Diversity Scholarship. And it's usually for people from underrepresented backgrounds. Maybe your company also can't provide a stipend or anything for you to go or maybe you're a student, have the funds to be able to go to a conference. The Diversity Scholarship allows you to get that experience. And if you're able to qualify for the scholarship, definitely apply because when I was first looking at Kubernetes, I thought it was pretty cool. But I didn't get a lot of opportunity to do a lot with it or contribute. But once I went to the conference, learned more about it and met different people, attended some of the break-off meetings for different SIGs and just learning and talking to people in person about Kubernetes and what it means to be a contributor, it really kind of pushed me and gave me the courage to go further into the community and become more involved. Also, I think that something that has been useful for me is just to be open to working on new things. Not only does it build rapport with the people that you're working with and different members, but it also could lead to potential mentorship or responses for when you do decide to apply to become a member, which we'll talk about in a little bit. So how do you become a member? Well, let's start by talking about what exactly is a Kubernetes member. So there's the status of contributor, which anyone can get just by making at least one PR to Kubernetes. So just once you make your first PR, you'll be labeled a member, I mean a contributor. You'll see that label next to your name whenever you work on stuff. To become a member, you have to be an active contributor in the community. So this means you're contributing fairly often. You've built rapport with some people and have been active in a few SIGs. And you also need to be sponsored by two active members as well. So that's what I was talking about earlier on when, you know, being open to taking on new tasks. I think the people that decide to sponsor me agreed to do so or offered to do so actually, because I was always, you know, willing to take on the work that they presented me. I showed them that I was like hungry to contribute and I want to grow myself as a Kubernetes contributor. So they kept helping to facilitate that and provide more things for me to work on. And then eventually agreeing to sponsor me. The next member status, I guess you can call it is reviewer. And that's someone who is reviewing a bunch of contributions within a sub-project and they've contributed quite a bit. And they're getting pretty experienced within that sub-project. And then finally there's maintainer. And that person has the ability to, you know, approve or, you know, say it looks good to me on contributions. And they're pretty experienced at this point and they've been actively reviewing in a sub-project and they also contribute quite a bit. Another tip for becoming a member, you see here pictured is a bunch of my contributions up until I got my membership in December and it's relatively consistent. You know, I try to, I would try to contribute every month. Sometimes it'd be multiple times a month. Sometimes I would skip a month and then pick it up again. But you have to remember just to contribute at your own pace. And when I say consistent, I mean, you know, you're actively and consistently asking for work or finding work to do. And then you're, you're finishing it till completion. And then, you know, what I did aim to do was to increase my scope as I contribute more and more. So, you know, you don't want to contribute. It's good to do those like, for example, typo fixes and things in the beginning. But I think that if, you know, you want to apply becoming a member, you just up the significance of your contributions over time to be a little more complex. And it's also so that you get more familiarity with the code base or the sub project because eventually the hopes is that you'll become a reviewer and maintainer. So try to keep those things in mind when, if your goal is becoming a member, and then also trying to have some familiarity with at least two areas of the code by areas. It could just mean like SIGs and the sub projects under those SIGs. For me, I worked with SIG testing and SIG cloud provider. And I was able to get a member from each of those SIGs to sponsor me just by doing a lot of work with them. So the membership application itself. That's probably the simplest part of the whole process, you know, obviously putting in the time and contributing. So the application is really just, you know, there's an issue template within the Kubernetes org people. Let's you fill it out. Basically, it's a template for filling out a membership. And you just put in all the links to PRs, contributions in terms of like comments or. Reviews, you know, participating in any issue. Yeah. Anywhere where you participated or contributed in some way. You kind of link that stuff up to the end of the video. And then also the SIG projects that you're involved with. And as you can see here at SIG testing and SIG cloud provider. And then, you know, Alejandro, that's Jorge. He's from SIG testing. He offered to sponsor me. And I worked on a bunch of SIG testing stuff with him. And then Andrew Sy came as a co-chair for. SIG cloud provider. And also I worked with him quite a bit. So typically your sponsors should be someone that you've worked with pretty closely. And they have a familiarity and good voucher for your work. And one more thing about the application. Once, once they like plus one it and, you know, basically agree that they did say they're going to sponsor you. It only takes like a day or two, I think, until like a bot. And then another Kubernetes member like approves it. And I think I make, they make a PR to make it official and then you receive a GitHub email. Asking if you would like to join the Kubernetes organization and GitHub. And then you get a little Kubernetes logo next year. You're. Naming your profile. So that's pretty cool, I guess. Another thing to point out is like, what you may find difficult along the way, you know, try not to let these things discourage you too much. Because I know when I was working through these things, it was pretty tough. You know, one of them being testing. Especially in the beginning, I feel like. Trying to figure out how to test my PR as locally was. Like. Took longer than the actual PR. And I just think it was a little tough because of the documentation layout. You know, some of this stuff. Is, you know, documented documented in multiple places. And kind of contradicting, you know, so for example, I'll put these links here, but like running and then test with basil. And that's the, I believe that's. The hack ETB director where these tests are run. I'm not mistaken. And then running into tests with Gingo. They both say in the documentation that these are the canonical ways to run tests, but, you know, I guess if it's canonical, there should be only one. So that that was a little confusing. And then if you talk to different people, you know, everyone has their own way of testing things locally. So I think that that personally for me was pretty tough. So I'd recommend, you know, if you're having trouble with this, just try to find someone. That's already a Kubernetes member and has experience with testing a lot. Their PR is locally a lot. Or at least just reach out to the sick testing channel. You know, they're super helpful and get put in the right direction. Just make sure to be detailed. With your question. And, you know, someone definitely get back to you. Also, getting feedback. It's pretty tough. You know, I remember. Especially in the beginning. I see this for people who are new contributors still. It's tough getting people to review your stuff. I think this also goes with the communication and the building relationships aspect of being a beginner. You have to kind of. I think there's like a level of trust, you know, once you contributed enough. And, you know, if people know about you, you know, you know, if people know about you and seeing your work or reviewed in the past and more willing to review it again, but if you're brand new, you know, they're not sure if it's just a. I drive by PR or someone just trying to stick something in or if a lot of thought was put into it or not. I think this can be mitigated a bit by maybe participating in some of the, the SIG. The related SIG meetings. Like for example, if it's a PR. Retaining to SIG cloud provider. Try to go to a SIG cloud provider. Or two and, you know, present your idea or PR that you want to make. Or bring up any questions that you have. You know, again, everyone's really inclusive. And I want more people to be a part of stuff to work it on. So, you know, usually these meetings will have times for you to, for new contributors to talk or bring up the issues of having or any PR as a need to have reviewed. And, um, if all else fails, you can simply DM. The issue created by the PR. So whoever made the issue, you know, just go check them on the slack and send the DM and remember to have empathy and patience. Always keep this in mind with when working with people in communities because a lot of people that I might have to reach out to are like super busy and juggling a bunch of things. And in my experience, they tend to get back to me some later than others. There's no bill will, or there's no, they're not trying to ignore you on purpose. They're usually just super busy. And usually what happens is they end up being apologetic and saying, sorry, Jeremy, that I responded to you a little late. I was busy doing, you know, X and Y. Here's your answer. So I just have a little empathy and patience. And then finding work as I addressed earlier. There's a high barrier. The entry to get into contributing. So, you know, I think. It was most likely due to, due to the analysis paralysis type situation. And that's how I feel. That's what I feel like got me stuck in the beginning was just trying to find something to get started on. So eventually I just started, you know, just started taking things when they would come up. So opportunities to, to work on things. I think that you just kind of got to get started, you know, either pick an issue or, you know, reach out to someone and then work with them on doing tasks and trying to be picky. You know, it's okay to be picky, but if you really want to contribute and get started and you're having trouble finding issues, just, you know, take work off people's hands. You know, everyone really appreciates that. And then the cooler things will come down the line later on as you, you know, build that rapport and build that confidence in your work. And last but not least, work life balance. I think that this is pretty tough for me in the past and still kind of is not sure that anyone has, you know, cracked the code to that in terms of, you know, balancing work, family obligations and then contributing in your spare time. It's pretty tough, especially if you work at a company that doesn't necessarily have a whole budget or department dedicated to open source on full time, you know, it does get a little tough. So I think, you know, communicating with your manager if you want to, you know, get some open source work into your day job. Also try to be deliberate about your schedule. So if, you know, with family obligations and things like that, try to like, you know, slot time out. If you can only do it on the weekends or at nights, it's fine. Just try to make sure you have a set time that you dedicate to open source work and don't deviate too much from it because they start sacrificing for you. And yeah, you know, just find what works with you. There's no pressure to contribute a certain amount of time. Everyone's different. Has different obligations and responsibilities. Just do what's best for you. Takeways. You know, anyone can contribute. I think that's important to remind yourself. You don't have to be, you know, at the biggest tech company, the, you know, the best engineer in the world or anything like that, or to be, you know, that doesn't even matter. I've seen a lot of contributors from, you know, super small startups. I never heard of them before I met them within a community, but they're like excellent engineers. So I don't think anyone expects you to have some type of prerequisite to be a contributor. I think people really just care about it. If you're passionate and if you're interested, you know, if you have curiosity, people will help. You know, feel that and give you the information you need and help, you know, facilitate your growth as a contributor. Also. You know, again, it's an inclusive community. Everyone's really welcoming. I feel like I keep repeating this, but like for me, it has been a really great experience. I think that, you know, being a contributor to contribute to Kubernetes has definitely helped my career and helped me grow more and more. You know, both career and personal growth. For example, this is my first webinar. And now it's reached out to you by someone at my company. They said, Hey, Jeremy, I know you're, you know, contributing to Kubernetes and, you know, you have a cool journey. Maybe you can share it. And the point is, you know, I think opportunities like this keep coming up. And for me, it has always been related to Kubernetes. And I think that, you know, they are interested in, you know, not only having you contribute, but helping you grow yourself as well. And then, you know, you also get to develop friendships and, you know, a lot of good, a lot of good things in terms of like experience, you know, like we're going to the conferences, pairing on, you know, code. These things are really important. And it kind of keeps me involved and I look forward to working with different people within the community. Yeah. So. There's also my links for Twitter. So Morris on 93. My LinkedIn is Jeremy, I'll Morris and go to my personal website. Jeremy on Morris.com. And I've also included. Links for some of the things I talked to on terms of the projects. A link on how you can make a PR and how to like get feedback on it. The diversity scholarship link. And then also information on the testing. The stuff I was talking about earlier. So I just want to say thank you to everyone for coming to my webinar. And I hope you were. He would have learned how you can be a contributor to. Thank you very much, Jeremy, for that wonderful presentation. We have plenty of time for questions. So if anyone has any questions, please feel free to drop them into the Q and a box and we'll get through as many as we can. The question here that says, please paste the link here. I don't know what. Link you're referring to. Could you be a little more specific? There's a question here. Any recommendations on local tools? Like development tools, like, like IDE and things like that. It says local tools. Okay. Yeah. So I use a VNL tool. I use a VNL tool. I use a VNL tool. I use a VNL tool. I use a VNL tool. Okay. Yeah. So I use a VS code. And I found it easier to use. Like a droplet to have all of my. So basically I use VS code to remote SSH into a droplet, a digital ocean droplet. And that's how it would contribute so that the droplet would always be there and it wouldn't matter what computer I was using. And I could just use VS code SSH into that. Excellent. Are there any other questions at all? Just a further reminder to everyone again that the presentation links, well, the presentation from today's webinar will be available on the CNCF webinar after the presentation is concluded. So we'll have it up shortly later today. If anyone has any other questions at all, please feel free to drop one into the Q&A box. What is your background? Oh, you see it. So we repeat these so that everyone can hear it. Do they see these? Absolutely. Yeah. What is your background in software engineering infrastructure? Yeah, so my background in software engineering is, I got a degree in computer science. Graduated. Like winter 2016 and got my first job. My first experience with Kubernetes was I had to write a trade study on like what a good container orchestrator and container run time environment solution and P for our needs. So yeah, mostly software engineering experience and infrastructure wise, I'll use Kubernetes here and there until finally getting to join the digital ocean Kubernetes team and working on that. I was quite a few questions. Yeah, we'll get to them. Do you recommend contributing to Kubernetes or any other related projects? Yes, I do recommend contributing to Kubernetes. I think that's a really good experience. You learn a lot. And then also any of the projects within the Kubernetes organization or the Kubernetes six organization. Do you have any tips on how to get from scratch to a dev and test environment? I think the question is asking like, how do you go from not having this stuff set up to being able to, you know, I guess work on it locally. I think, yeah, just, you know, look up tutorials and how you set up VS code and, you know, go need to have go installed. And then Kubernetes has some good documentation on how to get set up. I think if you look at any of the projects as a contributing project, I would definitely follow that to figure out how to get started. Do you like any other cloud native tools? Um, can't necessarily think of anything on top of my head, but I'm sure I use a bunch of other things. Does the contribution to Kubernetes require a wide expertise in development? Um, I don't think so. No, I think a lot of, I remember there was quite a few contributors that contributed a lot and they were, you know, just starting out in high school or something. So I think that Kubernetes tries to provide a lot of documentation, how do you get ramped up? Uh, even if they, you know, they will, they might assume that they're starting from scratch too. There's documentation for that as well. So there's no assumption that you have like tremendous experience developing software. Uh, something is that you just want to get started and then they have, you know, different documentation to address different needs. What are the VS code plugins that you're suggesting? I think it's, uh, there's like an SSH or remote SSH extension. Um, usually in VS code, you can just, you know, search SSH. I think it's like one of the top ones, but I don't know if the top of my head. What software language do we have to learn, um, to contribute to K8s? Uh, mainly go. Um, a lot of the stuff that you'll see is go. But there's also, I know that website project that I linked, that's in HTML. So there's, there's different languages, but I think if you learn go, you'll be pretty well suited to, uh, work on a majority of the things. Do we have any other questions at all? Plenty of time for questions, folks. Just feel free to. Drop in anything. Thank you in a box. Looks like we got another question. Which site do you recommend for language? Um, so like the. For, for going, I'd recommend the canonical. Let me just Google real quick what that is. There's a. They just go lane.org. I'd recommend that to start off with. Um, I think. You know, typically when I would talk to people about learning go or when I was first learning it, that's always the. You know, the site I get pointed to the actual, you know, the canonical one. So I'll start off with that. Okay. You have anybody else at all? Yeah. Well, no one has any other questions. We'll, um, Call this a day. Want to thank Jeremy again for a wonderful presentation. Oh wait, we have one more question here. Is there a way to validate my code before submitting a PR? Any tools available? Yeah. So I added some links, but there's the. The hack ET directory, which has, uh, some stuff you can run in terms of like scripts. Like a bash script. And then there's also, uh. You know, there's some, I think, I think mainly looking at those links and then also just looking at. Uh, Some of the documentation and reaching out to the sick testing channel. Again, everyone does things differently. Um, there's even, you know, you can utilize like mini cube and things like that too. You know, test things. Um, Locally before you push it up. Um, in terms of running the like the actual like CI tests. I don't remember at the time, I had exactly how you can try to replicate that. Or if you can, um, but yeah, I would look at the documentation or consult with the sick testing. Uh, stock journal. Have any further questions at all? No one has any other questions. I think we'll call it a day. Thank you all for attending. As I said before, we'll have the recording and slides from today on the CNC up webinar page at CNC up.io slash webinars. Thank you all for attending and everyone take care. Stay safe and have a wonderful day. Take everyone.