 Yep. Go ahead. Yeah, it's working. I think people can hear me, yeah? Then we're getting it on tape. Hi, everyone. This will be the last talk in this auditorium for DEF CON for 2018. And we have Josh Berkes, who's the Curvidities Community Lead, who will be telling you how you can be a communities contributor. Thank you. Well, welcome, everybody, to the last talk of the session of the last talk slot of the conference. We'll be talking about contributing to Kubernetes. Just to be clear, I'm Red Hat's Kubernetes Community Manager, which makes me one of seven or eight different community managers in the Kubernetes project. We have ones assigned from the other corporations that can contribute on a corporate basis. And this presentation is actually a super cut-down version of a three to five-hour tutorial we regularly do at KubeCons. So I actually have a lot more material than we're going to actually cover today. Hmm. Oh, hold on. I have a lot more material than we're going to cover today. So I actually wanted to get an idea of where people are so that we can cover the most relevant stuff. So out of our small crowd of folks who are here in the room, how many of you are currently using Kubernetes for something serious? Okay. Those of you actually said you weren't using Kubernetes for something serious. You just learned about it. You haven't done anything with it yet. You just learned about it. For those of you who actually are using Kubernetes for something, are you currently involved in the Kubernetes community at all, like socially or getting help or anything else? Okay. Yeah, kind of. Right. And from that, I'm going to guess is the only actual contributor to Kubernetes we have in the room is the one I already know about. So, um, so in that case, we'll go from the beginning here. So when I first got involved with Kubernetes, um, uh, before the release of Kubernetes 1.0, um, it was a lot like showing up to ride in your friend's sailboat where you show up and you say, hey, yeah, I want to go out in the water too. And they're like, great, hold this rope and don't let go until I tell you. Um, and so it was very easy to get involved and end up responsible for a whole bunch of things that you weren't necessarily sure you wanted to do in the first place. If you join the Kubernetes community now, it's more like getting on one of these giant floating hotels that they call cruise ships that host 6,000 people, um, because we have something over a thousand contributors. And so part of the idea of this talk is that I'm standing in for Captain Cates here, um, and giving you a little tour so that this gigantic floating hotel that is the Kubernetes project can be a little bit less confusing, um, in terms of you finding where you fit in. So there are really two basic reasons why people contribute stuff to Kubernetes. Some people are really excited about orchestration or distributed systems or microservices or, uh, controller managers or operators or something else. And they want to tinker with those things. Um, and some people are, for example, working somewhere where they have infrastructure that is dependent on Kubernetes and therefore they need to change something or they need to make sure that something keeps working. How many people here would be are here in the room because they're in the first group? Okay. How many people are here in the second group? Okay. Wow. So a lot of, you know, how many people in the second group work for Red Hat? So is that most of you? Yeah, that figures. So, okay. Um, so there's both of those. And those are both completely valid reasons. Like we're not, you know, expecting one group to be the other group. Um, and some people both apply honestly. Um, but so I actually put together the new contributor workshop with one of your Sanger, um, who also gives it at some of the Kubecons. And she has this great story where she got actually involved only late last year. And she started out by jumping on to GitHub and filing an issue that our contributor documentation was horribly out of date and completely disorganized. Three months later, she was the lead author for our contributor guide, which by the way, um, there's that link, uh, akds.io community contributors guide. Read me. Um, I've got, that's right here. And that actually covers in text form a lot of the material that I'm about to go over right now. Um, so that is where you would follow up in this presentation to find out more. Um, this can happen to you too. So how, we can break down what happens when you want to contribute to Kubernetes into sort of six steps. One is where our foundation project, we have a CLA, um, for anything you're going to do in GitHub, which is more things than you would think that would be on GitHub. Um, you need to sign the CLA. So do that somewhere concurrent with figuring out where you're going to contribute first. Second finding first topic, a first thing, a first thing that you want to get involved with, find a SIG and I will explain what that means in a minute. Make a contribution, spend a lot of time arguing with bots, um, because we rely on bots for GitHub automation heavily, um, and then become a Kubernetes org member. And then there are steps beyond that, but this is, this is the beginning. This is the first contribution dates. So like I said, foundation project, cloud native computing foundation. We require a CLA to assign stuff. There are two versions of the CLA one for individual contributors and one for contributors whose people who are employees of a company that support the project. Um, and it's fairly straightforward. There's an automated process to signing it and submitting it. Next, and this is the more fun part, um, you want to figure out where it is you're going to contribute first. What is going to be your thing? Um, and there are a lot of things to choose from. Now, there's a bunch of things. I mean, some people just want to get involved with the project and want to improve things and that sort of thing. A lot more people get started where they need a specific thing from Kubernetes. So anybody here actually jumped in like maybe when they came in here because they already maybe filed a bug or they were thinking of filing a bug around something that was broken with Kubernetes. Anybody? Okay. Haven't gotten that far yet. Yeah. What was it? Things that we're solving with like Rancher or other things. Yeah. Okay. Okay. Yeah. So it's a pain to figure out how to configure a Kubernetes as part of your larger system. Yeah. Well, that's fine. This is actually all about Kubernetes. Honestly, this whole talk is about the upstream project. And honestly, some people actually are more interested in our community. We have a gigantic community. It's actually very welcoming. It's a lot of fun. A lot of different people in it. So some people just pick things up based on where it is they land in the project. And they're like, oh, I'll work on that. And you can do any of those things. This. Okay. Now, one of the first places that people contribute is going to be documentation in the website, which in the Kubernetes project are the same thing. They're the same GitHub repo because the website started out as documentation only the same GitHub repo there the same team. And pretty much everybody if you've used Kubernetes seriously have come across the dock page that was out of date or wrong or incomplete. And that's just one of the first things like all of us are pretty much who are contributors to Kubernetes in any way are also doc contributors because you end up improving the docs and they have a really good workflow for that. And it's actually a really good place to start because it doesn't require you to know about the testing and doesn't require you to know about the go build stuff or any of the other things. The other place that a lot of people don't think of as an area to contribute is we do a lot of automated testing for Kubernetes and a lot of test infrastructure and a lot of process automation around our CI CD Street. So if you're actually interested in CI CD, if you're interested in testing distributed systems, etc. Kubernetes actually a great project to get involved with because that team always needs more people and there's a lot of interesting problems to solve. And then of course, a lot of people contribute to the Kubernetes code. Whether core Kubernetes itself or any of the many, many satellite projects that are integrated with Kubernetes to a greater or lesser degree. As a matter of fact, if you're starting now, you're more likely to be working on one of those than working on any kind of core code. Well, work has actually honestly slowed down a lot. So find your first topic, your first area because you notice a bug, you want to feature, you want to improve something, you're trying to learn stuff. You have time to work on open source stuff and you want to do something interesting or you just want the documentation to not suck. Any of those things. Find that just like any other open source project. Now the next stage is to figure out how to actually do that contribution. And this is part of what I need to talk about how we communicate in the Kubernetes project. So again, I mentioned over a thousand contributors and over a thousand means a heck of a lot of talking in multiple different media. So now before we go into the various places, you can contact people and you will get involved in talking. Let me say first of all, we have a code of conduct. We believe very strongly in contributors respecting each other and treating each other well. So that's it's a critical thing. It's very important for us to remain a community where anybody feels safe contributing. And for that reason, please don't bring baggage with you from other communities if possible. The other really important thing about that is remember to use emoji. That's also very important to our community. So various places to ask questions. So we have a discourse board called discuss.community.io. It's relatively recent. It went up about four months ago. So it has less traffic than some of the other things, but we already have a whole section in there for contributing to Kubernetes that gets used. Plus it's also a good place to interactively discuss problems. Like, hey, I'm looking at Ingress controllers and what are the pluses and minuses of the different ones? Good place to ask that. Interactive chat, slack.kubernetes.io. We use Slack very heavily. People do both development coordination and user discussions and stuff on Slack. If you just have sort of support-ish questions, we really route those over to Stack Overflow and Stack Exchange and not to the sort of contributor forums, because otherwise we tend to get overwhelmed, although you can also ask a lot of those in discuss.kubernetes.io as well. Now, so if you're specifically looking for help contributing, there are various mechanisms, right? You can use Slack, you can use Discuss. On a monthly basis, we run a forum in two different time slots that is a combination of live video and chat called Meet Our Contributors, where it contributes to various sorts. Like actually next Wednesday, we're going to have four members of the Kubernetes Steering Committee hosting that to talk about various things, and that's a good question to ask questions about, say, governance, for example. We have these contributor summits before every KubeCon of the three, at this point, three KubeCons per year. And like there, for example, Shanghai, with a bunch of people who speak Chinese a lot better than me, we'll be doing a full day version of the new contributor workshop, et cetera. And so that can be a good way to get started if you can afford to go to a KubeCon. And then there are a bunch of other mentorship events. Some of the SIGs have one-on-one programs, some of the group mentor programs, that sort of thing, that you can get involved in if you want a more structured environment for contributing. And then when you sort of get into contributing, you're going to use some other communications methods in order to continue, the biggest one of which obviously being GitHub. GitHub issues and PRs, a lot of actual project communication goes on through those, including design discussions and that sort of thing, like the way somebody, like, if you're going to design a new API, you'll post either, depending on how far along you are, an issue or a PR, and then people will discuss it and pick it apart and a lot of other things until we nail down what we actually want. We also do a lot, a lot of video meetings usually via Zoom, because that's been the least bad video conference and platform we've been able to find. And this includes regular meetings for SIGs, and again I'm about to explain what SIGs are. And then, of course, we have face-to-face meetings and we have developer meetings around the Kubecons, and then some groups will individually do face-to-face meetings, like we had recently at the Helm Summit in Portland for people who work on Helm. So I mentioned SIGs, like, at least five or six times now. Those of you are brand new to the Kubernetes, who haven't been any involved in the Kubernetes community before. SIG stands for Special Interest Group. It's an old term in computing. We're using it in the same sense that the IETF does, which is that the SIGs are the sort of building blocks of the community. Each SIG is a department, and they have authority over a particular area. And in a lot of ways, the Kubernetes community is actually a collection of SIGs, as in the SIGs and the SIG leaders have a lot of authority over how the project runs and what's acceptable and what's not acceptable, etc. And even some slightly different character and how they handle contributions and mentorship and other things within the individual SIGs. I do have an opportunity to flip through this really fast because if we went through it slowly, it would be the rest of the time. There are, I believe, 41 SIGs and then some other organization types. But you can actually kind of go into sort of different areas with SIGs. If you're just getting started, you're most likely to be looking at one of the SIGs in the feature areas, and that would include things like authentication, node, which is management of the individual machine, scheduling. If you're into improving Kube control or adding to it, you might get involved in SIG CLI, you know, all of these things. And that's generally where you're going to start with. But there are other ones, like for example, SIG cluster lifecycle and API machine or any instrumentation handle a lot of the plumbing that holds together the other parts of Kubernetes. Or if you work for or involved with or implementing on a particular public cloud provider, those all have their own groups to manage all of the plugins for those. Or this is where I spend most of my time. There's a set of SIGs that handle a lot about how the project runs, like SIG release and contributor experience. And I'm basically giving this presentation as part of my role in SIG contributor experience, which is concerned with how do people contribute to Kubernetes? We have a group for that. This is generally for the when you've been involved for a while though, because you just hop into one of these are not necessarily what you know what's going on. Caveat though, this is exactly where a couple of people have started, because they wanted to improve things for other contributors rather than hacking on stuff. And of course, the number one, the entry point for new contributors, which is SIG docs, which also documentation and website. Huge SIG, lots of people, very organized program for new people getting involved, which is why it's nice to interview there first. Now there are some other things that you'll see people thrown around. There's working groups and working groups are generally task-based organizations, like the resource management working group that's specifically looking at how you control things like memory usage within Kubernetes. Or sub-projects that are fairly specific projects under a particular team, like under SIG API you have the cluster API team that's looking just at the how do I manage a whole cluster through a single API. There's new API that they're building. And if one of those projects is your project, you may join that sub-project. But if you join a sub-project, you probably also want to join a SIG as well for sort of community reasons, because the sub-projects don't generally have much involvement in how the overall project runs. So basically figure out where you want to work on first. Figure out who covers that, which is probably going to involve like Pinguis and SIG Contribux and Slack. And saying, hey, I want to work on X. Who's that belong to? Because some things like CLI are obvious, but a lot of other things are not in terms of who's responsible for them. And it's better to just ask. And then attend a couple of meetings so that you can actually see how things go and so that you can introduce yourself to people. Now, if you are looking at contributing to, well actually looking at contributing anywhere, you probably want to be aware that we have an enormous number of GitHub repositories covering just about everything. They're very disorganized right now and so we're in the process of moving them around in order to make them more rational. But in general, we have a few things like there's the core repository, which is Kubernetes Kubernetes, which we're honestly actively trying to move stuff out of because we're really trying to make Kubernetes become more of a plug-in infrastructure. And plus the core repository's gotten really huge. So we'd really like to actually take stuff out of the core repository, but that's also a very hard thing to do. There's a bunch of repositories that govern the project. Like if you were actually like in sync contributor experience, we spend a lot of time contributing stuff to the Kubernetes community repository, test infrastructure, performance tests, that sort of thing. Again, all have GitHub repos. We have the docs and website, which is starting to branch out. We have the main K website. So if you look for the documentation repo, you're not going to find it. The repo is actually called website. And then we're starting to have separate translation repos for things. Then there's actually a bunch of repos devoted to tools for the development of Kubernetes itself, which you would only get into if you're a tool geek. Some of these might actually use this thing called staging repos, which are actually portions of Kubernetes, Kubernetes that are broken, mirrored onto a separate repo for ease of development. So if you're actually working on things like the API server, you're actually likely to spend a lot of time working with a staging repo instead. And then some of the SIGs have their own repos, but most of them don't. Most of them have their own directories within the main repos and other things rather than having their own repos. Oh, and a few of the Cloud providers have their own repos, but not all of them do. So for any of things. And then remember how I said, if you're starting to contribute in code, you're actually a lot more likely to start with a satellite project than you are to start with the core project at this point. And so there's a whole bunch of repos for there, some of which are in the Kubernetes namespace, some of which are not. And also the Kubernetes SIGs namespace, which is where a lot of the sub-projects are. But again, if you're into a lot of these things, you want to improve Helm, you want to improve Minikube, you want to improve the installation experience, something like that, you're actually going to be going to one of these satellite repos. Now, one of the important thing to know about all of these repos is that the project allows the developers who manage a particular repo a lot of leeway in the workflow of that repo. So we have a whole lot of writing like the contributor guide and stuff about how stuff works. But by how stuff works, we mainly mean in Kubernetes, Kubernetes, and a few of the other core repos that are under central project management. If you're actually contributing to something like Helm or COPS, you may find that the workflow there, in terms of how things get approved, how things get reviewed, et cetera, is very different. You have to find out how it's different interactively. Just be aware that it will be different. Now, one thing that we are enforcing project-wide but is not yet complete is the use of owner's files, putting owner's files in project route and in every directory so you know who's responsible for a big good piece of code. And if you are getting started contributing, these owner files are extremely valuable to you because you're like, hey, I'm really interested in adding this extra interface to this particular thing. Who do I ask about? And the owner's file, look in the owner's file in that. If there isn't one in that directory, look up the directory route. Find out who's actually involved with it because if you can ping individual names, you're more likely to get a response than jumping on a SIG's channel and asking the group at large because often is not the person who actually has the answer for you is in a different time zone and if you don't tag them in your question and they get online 11 hours later, they won't see. So use those owner files to look at it. And later on, you will need the people that own the files to approve your work. So better to make friends with them now. The first place that you get started contributing often is actually through issues. And I know every project says issues are a contribution but in Kubernetes, we really mean it because one of the terrible things about distributed systems that take lots of plugins is the combinatorics on the different things that we theoretically support are really insurmountably large. You know, we have the giant testing group and hundreds of automated tests and they still cover less than 10% of how people actually use Kubernetes. And so if you have a way of using Kubernetes that is maybe different from what is automatically tested, your response on how that worked or didn't work is actually extremely valuable because we have no idea otherwise. So contributing bug reports is often where people start as you go in there and the first thing is to find the right repo for the bug. And if that is confusing ask again, jump on discuss or in Slack or something else and say, hey, I found a bug in X where do I file bug reports about it? We do. I mean, I'm giving this into the Kubernetes community repo. We have a lot of description of who owns what. You'll discover that description is really complicated because there's a lot of stuff to own. Really asking people is the easier way to find out where you should file these things. Your first time. Create a complete and detailed bug report and then very, very important follow up when people respond to it because if you file something and you don't follow up chances are it's just going to get deleted as won't fix because people don't have enough information to help anything. So get some example of, you know, a complete technical bug report. We also accept bug reports on community process things and things that are not technical. Also, if you want to change things about Kubernetes like say you want to add support a new driver or support a new API or something else add a tool other contributors going to want a specification for that and you will create that specification in the form of an issue. Create an issue of kind Kubernetes of label kind feature and give a spec for what it is you want to change and how and why and again follow up to the responses and the arguments and the discussion that you get on that. So, and then the proper workflow is you then go from that when you get more or less agreement on that issue of what's going to be done next then you write the docs or work on writing the code or whatever in order to create a pull request for that. Now, I'm not going to go into this in detail as part of organizing all these issues we do have a sophisticated system of labeling issues in terms of labeling what kind of an issue it is and who owns it and that sort of thing. Again, you can ask for help here and there's a bunch of documentation in the contributor guide for what all the various labels are for and which ones you're required to put on. Just know that you will be required to put on some labels and then other people more experienced to the project will be putting on labels for you. Now, follow up with all of that and here's an important thing. When you find out what SIG or work group or whatever owns the area that you want to contribute to follow up with them socially on Slack on a mailing list in a SIG meeting so that people in that SIG are aware of the thing that you want to do because otherwise stuff can languish for a really long time without any attention because we get I don't know whatever it is a thousand issues a month something like that. Documentation I talked a little bit about in these terms and contributing to documentation really good place to get started. There's a website repository. They're very responsive via Slack. It's a good way to actually connect with the documentation team. The they have a whole branch set up where the core thing going forward is master but they have branches for each major Kubernetes release so that we can have past versions of the docs for using older versions of Kubernetes. Now once you have an issue that you have consensus on then you're going to be looking at actually creating a pull request. Now I'm not going to go over how pull requests work. You don't know already learn that online. We do have a lot of people who basically get started with GitHub via Kubernetes. So there's that track available and we'll just sort of explain that. What I would say more is when you're looking at stuff like for example say the issue isn't your own but you're saying hey I want to get involved with Kubernetes. I want to find out how stuff works. I want to find out how the API works. So I can contribute my own thing to it later. So in the meantime let me do some stuff. So there's two tags that are used sporadically in existing issues. One is help wanted and the other one is good first issue. Now good first issue means it's almost always something that a new person can get started. Issue maintenance is a thing so do double check that it's still a valid issue at this point on Slack or otherwise. Help wanted tag theme to be all over the place. Sometimes it's help wanted because it's a good first issue. Sometimes it's help wanted because we need somebody who has specialized knowledge in order to resolve this issue. In which case unless you happen to have that specialized knowledge this is not actually the place for you to start. The go through branches and a couple of other things. Now obviously it's a bunch of general stuff for pull requests as applies to almost every project. Keep your individual PRs as small as possible. Make your commits logical squash commits if you need to. Put in commit messages that explain everything even if you're going to explain a whole bunch of things in the pull request as well. And this is something that is not well-onored even by experienced Cooper days contributors. We harass people about it all the time but please please do that. And you know obviously look out for committing a rebase or something else where you've got unrelated material because that will tend to not your stuff reviewed. Open your pull request what you're immediately going to response from will not be from a human being but from a GitHub bot. And that GitHub bot may tell you that you need to make changes to the pull request to make it acceptable. It almost certainly will if it's your first pull request. So look at those instructions and follow them. We work hard on making those instructions actionable so that you can follow them. If you can't understand them again hop on slack or discuss and say the bot's telling me X what does this mean? Make sure your CLA is signed because this is the point where you need to have a CLA or we can't take the pull request and then wait for a reviewer or plead with somebody to review your thing and they can actually put in the okay to test label so it goes into the automated testing. If it's your first contribution it doesn't get tested automatically because we don't want people to put in Bitcoin miners as pull requests. So we go through all of this and the bot puts all kinds of tags and you'll notice a lot of labels are generated by the bot to tell us the status of things. It's really a very heavily automated project we're making up for all of GitHub's many limitations with bots. You can talk to the bot you can assign things it'll tell you have to assign something to a SIG and you do that with these backslash or forward slash instructions. Also going to have fun sometime the putting the forward instruction wolf or meow just do it. Follow up on your pull request if your pull request is not getting reviewed and you found out which SIG first of all if it's not assigned to a SIG it will almost certainly never be reviewed. So find out what SIG it should belong to make sure it's tagged with that SIG and then go to a SIG meeting and get yourself on their agenda to say you know hey I submitted this can anybody take a look at it? I mean be polite out of new stuff into the project all the time and sometimes you do need to actually get in front of a person. Look for failing tests and fix the reasons why they fail and then discuss and obviously be nice if you start shouting at people most likely they're just going to close your PR and if they're not being nice then come to SIG Contravex and we'll work it out. And then you know get your stuff merged and then you're a Kubernetes contributor which is awesome. Once you're a Kubernetes contributor or even if you joined a team and taken on some volunteer responsibilities but not actually contributed anything yet apply for what we call org membership this is in GitHub org etc. It's like your sort of first step on Kubernetes later it's basically saying hey you're a real person and you've got some commitment to contribute to Kubernetes it means that the bots will listen to you more among other things and it's also the first step on what we call the contributor ladder and we are very very interested in moving people up this ladder because particularly on that approver and owner level we do not have enough people so we would really like people to move up from member to reviewer to approver to owner so we have more maintainers of our rapidly growing code base so we want to help you move up that way. So basically get there now one of the things is the process for asking for org membership changed recently from a process that depended on email to one where you open file an issue against a repo and we're still working on some of the details of that so if you're doing this next week it could be a little janky just you know go to the org repo file an issue request an issue and say hey I should be an org member because X preferably get find someone else in the project who will endorse that via whatever of our many discussion media that you have you can help with contributing again SIG contribex meet our contributors on Slack discuss.coupernaise.io all of the general events you can even join a structured mentorship program and again the place to ask about that would be on SIG contribex and most of all remember to make friends open source is fun it's often chaotic people are contributing to Kubernetes because they like it and because they're enthusiastic about it and if they hurt your feelings they probably didn't mean to and if you see something that's broken or needs fixing or whatever treat that as an opportunity and most of all talk to people so we are at the end of our time slot yeah? Yeah, I take a couple of questions and please do use the mic I, well it's from the other speakers I have an air conditioner directly behind me so I can hear him but really nobody in the back so you mentioned that that you have tags in some of the refills so do you have particular levels of experience for certain people? for example at Apache some of the projects what they do is they have apprentice bugs or first bugs do you guys have labels and tags like that? that would be nice but no no it's really limited to like good first issue okay another question? yeah I mean our big issue is even with good first issue we have trouble maintaining those because the problem is that stuff is tagged good first issue and then people forget about it and then it becomes no longer relevant because say the underlying API has changed I mean that's why I said when you find a good first issue if it wasn't, if it was filed more than a few weeks ago do double check that it is still valid so you know maintenance of things that have been open for a long time is always an issue okay well thank you very much I hope to see some of you online on GitHub and discuss and Slack as potential Kubernetes contributors in the future thank you thank you all so we'll be skipping over the afternoon break and heading straight to the closing ceremony we do have some fabulous prizes to be given away there will be a trivia game conducted so please be there thank you