 So, hello. Welcome to the Contributor Experience deep dive. So, a little bit about us. We're one of the 25 special interest groups, which are in Kubernetes. So, in this talk, we're going to go over who we are, what we do, and how we do it. So, I'm Allison. I see a lot of familiar faces over here. So, hello, and thank you for joining. I'm a co-chair of Contributor Experience, along with Bob, who, as Miles mentioned, unfortunately couldn't make it along with us today. I'm based in the UK over in London, and, yeah. And hi, everyone. My name is Christoph. I am a tech lead for Contributor Experience, alongside with my colleague Nikita, who also couldn't be here today. I am based out of British Columbia, Canada. No matter how you slice it, Kubernetes is a large project. And at the core of it, it's the contributors that really bring this project to life. Of all the numbers on this page, that's the one that I want to draw your attention to. So, that brings us to who are we? What is Contributor Experience? Summed up, we're a cross-cutting special interest group that is focused on the experience and workflow of all contributors to the project, both experienced and brand new. We're made up of folks with different backgrounds, companies, interests, but we all have the focus to make Kubernetes a better place to contribute. If you have no idea where to contribute, then we'd be honored to be your first sig. It's not uncommon for people to hang out with us while they learn how the project works, and then eventually move on to a sig that is more closely tied to a specific part of the project that they're interested in. Okay, but, like, what do you do? While most other sigs are focused on a specific part of the project, Contributor Experience spans the entire scope of Kubernetes and how folks contribute to it. We interact with contributors at all levels, both those just starting out with us and who may need assistance learning about how to contribute, as well as folks in leadership positions providing them with the tools and processes to be successful. A lot of what we do is centered around defining policies and providing consistent guidance for folks. We strive to give contributors a consistent experience across the project, no matter what sig or piece of code or documentation that they're interacting with. Like any sig, we have meetings and details about how to reach us on the contributor site. No matter which sig you're wanting to get involved with, our contributor site is a great first spot to kind of go look at that information. There's a couple links in the slides. Next, let me talk for a minute about how we organize our work. With the size and scope of things we do, we establish some teams of folks to help organize the bits and pieces. For example, we have folks like our moderation teams that help keep our communication channels safe, like our mailing lists and Slack and making sure that they're spam free. We have the contributor marketing team that helps communicate information out to that large contributor base. We organize the work we do into subprojects, just like any other sig. This allows us to split things out and then delegate that work out to responsible parties. Some examples include our contributor site and community repo, which house details like the central sig list and our community calendar. Another example is our mentoring subproject that helps us organize our participation in external mentoring programs, as well as our internal programs like meter contributors. So now that I've explained a bit about the type of work we do and how we organize, let's dive a bit into some of these subprojects, which will give you all a better picture of what we've been up to. So all these subprojects, so community management is one and community management is at its core community operations. So first thing in this list here, we've got mailing lists and calendars. So if you're familiar with Kubernetes, you probably might have signed up for some of the mailing lists here. So we have like mailing lists for all the different sigs and they're all hosted on Google groups. Collectively, we have about 50 different calendars and mailing lists, all which play an important role in the running of the entire project. Currently, we're working on an effort to move all the mailing lists from Google groups, so groups.google.com to capes.io under G Suite, which will help us scale more and more larger because I think one of the big issues with the current setup is, it doesn't have the right capacity and there's more issues and yeah. So more about mailing lists and calendars. So a SIGS mailing list provides a place for a SIGS specific communication. You can ask questions, facilitate decision making, have discussions and share meeting notes with others. So by subscribing to a SIGS mailing list, you'll be automatically invited to all the meetings on that SIGS calendar so that you as a contributor only have to worry about signing up for the mailing list you're interested in than filtering out your emails as needed. So next up, we have youtube.com slash Kubernetes community. It's the channel home to all of our YouTube videos. So here you'll find recordings of SIG meetings, as well as top level meetings, which includes our monthly community meeting, meet our contributors, we've got instructional videos, code walkthroughs. There's even the contributor workshop. All recordings of that are available on the Kubernetes community YouTube and many more that I probably couldn't list in this time here. So we also from time to time do a bit of like live streaming and we live stream special events and meetings. So for example, we had the events for the contributor celebration held December last year. So you might have seen on the Kubernetes community YouTube, like there's a there's the live like recording of the the Kubernetes Bake Off that we had the cloud native Bake Off. So by subscribing to this channel, you'll be kept up to date with what's happening in the community. So make sure you go to Kubernetes dot com. I mean, YouTube Kubernetes dot com. Go to youtube.com slash Kubernetes community. Hit that subscribe button and mash that Bell button. Yes, got the YouTube hype words there. So community repo. So Kubernetes slash community is where our community repo lives. And here we will find things such as governance, election procedures, values, code of conduct. And and yeah, any project that revolves around the Kubernetes project as a whole is owned by this project. So another thing about elections that I'll just chime in on this note here. There is currently, you know, there is an election happening for the steering committee. You can check that out online. If you just go on a Kubernetes slash community and you see in the there'll be an elections folder, I believe. And yeah, it'll be right there. So forgot to put that in the notes here. So zoom, we help with managing the licenses needed for a sick chair so that they can use zoom to record their meetings. So if you're not a sick chair or lead, you don't really need to worry about this. But if you know how to administer these tools, we can always use more help. If that's not your forte, you as a contributor can still help us out by keeping zoom up to date. This makes this this makes it easier for us to use new features in zoom and helps keep you secure. Discuss dot kates.io is our end user forum and it's powered by discourse. It's a more user friendly way to have discussions. It's a great resource if you want to learn more or have questions about operating Kubernetes like so for instance, if you go into that discuss dot kates.io right now on your phone, you'll see there's so many like Fred's and things where people are asking help. I'm stuck on this. Can you help me out? And it's a very active form forum. So 10 out of 10 do recommend. So with all these different platforms that we have here, we rely on moderators. We strive to make all our communication platforms a safe and inclusive space for people new people to come in. And we would not have a really great community with all of you wonderful people here and watching online. We wouldn't have an amazing community like this as we do today without like our moderators. And we're always looking for more moderators across all time zones. So if you're experienced it, if you're experienced with community moderation, like you've managed some slack or some discord or something like that, we would love to hear from you because yeah, we always can use my help. So yeah. So you've just heard about all these different communications platforms that we have. So with all these different platforms, it can be very challenging to reach our contributors, which brings us to our wonderful marketing team, aka contributor comms who help us engage with our upstream community. So contributor comms used to be a very small group under community management. And it's since grown becoming and it became like an official subgroup of so contributed experience in November of last year. So yeah. And Kesslin's doing some really awesome work there and helping like with those efforts. So I just want to shout out to them right now. Like, thank you. Thank you. Marketing team. So there's a talk link here in the slides if you want to learn more about the marketing team, its story or the backstory, you know, if you want to learn more. So do go check that out. So next up, our contributor documentation. So it's a set of living documents which cover, you know, two broad areas. So we've got the contributor guide, which provides the base set of knowledge for a contributor to be able to effectively help out in our community. If you're involved with Kubernetes or wanting to get involved, this is something you should definitely take some time to read and understand. So our developer guide provides information, provides contributors with information on how to contribute to six specific areas of the project. So things like how do you set up your specific, how do you set up your development environment if you're going to contribute to say six CLI? How do you set up like, how do you just, yeah, six specific stuff? Yeah. So API conventions and style guides, stuff like that. So it's currently undergoing some audits and updates to ensure that the information on there is correct. So a big shout out to Joel Barker and Eric Arnson, who have helped restructure this guide and updated some most needed areas. And thank you to all the six who have been really like, who have been really proactive with updating their documentation. Because it really helps a lot when like, you know, you're new to a community and you need to find, oh, what is this sigil about? Like being able to understand how, you know, to contribute, like how do you set yourself up? It's great. So went on a little bit of a ramble tangent there. So on both these areas, we're both looking for help revising them, especially from new contributors who can approach them with kind of a fresh perspective. Because I think we, a lot of people like who are experienced, we can kind of miss things out and we're like, oh, we already had this thing installed. And it just kind of goes under the radar there. So yeah, definitely check that out if you're like looking for something to contribute to. So next up, we have the contributor site at kates.dev. So it's the contributor site, which went live towards the end of August last year is a hub for contributor docs and information. It's got the contributor guide, which we just mentioned, the community calendar, the release information and much, much more at the moment. The developer guide isn't surfaced on the website, but we hope to have it there in the future. So yeah, next up, we have dev stats. So you probably might have seen the talk earlier in the conference. I believe Dr. Dawn Foster did a really good talk about beyond stars and four stars and forks, you know, measuring the health of your CNCF project. And it touches a lot on dev stats. So I'll link that later. But anyway, for people who aren't familiar with dev stats, dev stats is a tool that helps us visualize GitHub activity. It uses the GitHub archives and data to crunch a bunch of stats and then calculate, you know, GitHub events. So this can give us huge things like how quickly PRs are getting reviewed, how quickly are things like getting seen improved, who's contributing. It's where we got some of the numbers for that first slide that you saw earlier about our number of contributors. We've been revisiting the board so we can get more actionable metrics. For instance, we can find out if a repost got a bunch of open PRs. And then we can relay that message that we need more reviews. So case.devstats.cncf.io. Yeah, that's where you can find that. Now I'm going to hand you over back to Christoph, who will talk about events. Thanks Allison. So with the pandemic impacting everyone, we kind of needed to adjust our strategy for how we hosted and manage contributor events. We would normally host multiple contributor summits a year to allow people to kind of come together and learn. But that didn't, for obvious reasons, didn't quite work out the way we expected to. We polled our contributors and, you know, with everything that's kind of gone on the last 18 months, only about 10% of respondents were interested in more regular structured content with 80% wanting to do something more social. So we have put together things like we had a contributor celebration on Monday night. We're looking to kind of put more emphasis on some of those social events to allow to bring our contributors together, both in person as well as in virtual settings. And, you know, a great example of that is we had last year we had a contributor celebration event near the end of the year where we had like trivia and board games. We had things like a contributor bake off as Allison mentioned earlier. You can find a lot of those recordings on our YouTube channel. They were popular. They're a lot of fun and their ways to kind of allow contributors to cut to kind of come together because, you know, something our first community architect, Sarah Novotny, it says is like our belonging is very high in this group. So we're not quite sure yet what things are going to look like for 2022 as we go into to future cube cons, but we're figuring out something that we want to do because having those having a very kind of tight knit contributor community something that's fairly important to us. GitHub management. So this is the sub project where the GitHub management team manages how contributors interact with GitHub. We have different organizations and lots of repos and, you know, again going back to our, what I was saying earlier like we want people to have a consistent experience as they're contributing to like 200 plus different repos wanted that to be like a want to feel the same as you're you're interacting with each of them. So, we've got a couple things in flight right now. We are working we provided a guide out to all of our sub project owners who own these repos about how to change the default branch configuration from master to main. And how to do that in such a way that it doesn't like break any of our automation and any of that. So, some repos have already started migrating and and in the near future we'll be looking for how we do that with the core like kubernetes kubernetes repo and some of our our core repose that we wanted to take a little bit more time and have a little bit more surety in the process before we before we pulled the record on that one. So another thing that we've got going is we're currently in a process of migrating from our old legacy CLA tool to a new tool called easy CLA. This is for multiple reasons number one the old tool wasn't actually open source it was a closed source product. So we wanted to move to something that was that we could enhance that we could see the code we could make changes if we needed to, as well as the old CLA tool if you ever used it like it wasn't it was very opaque as far as if you hit a problem with it. If you've signed the CLA and it's working for you it just works and you don't need to think about it. But if you ever have problems with it. It's very hard to kind of diagnose those errors and figure out what what the root cause the actual problem is. So the new system will have a lot more clarity and transparency around. Oh, it's like this particular commit is broken for this reason, or and this is the things that you need to do to fix it. So that we're kind of in a soft launch period right now, and we'll soon be looking to migrate over all of our GitHub repose into into that. So I want to talk about mentoring for a moment but I need to go over a couple prerequisites first. So, if you haven't seen this before, this is our contributor ladder. So this is the this is the process and kind of a path that we have created as far as allowing contributors to kind of understand how our project is organized and to facilitate growth within the project. So, when somebody starts out new their non member contributor. When, once you've kind of got some contributions on your belt, you've developed some relationships, you can get some sponsors to put in an application to become an org member. Once you become an org member, there's some benefits there like we trust the tests that you're running. And so you don't need to wait for somebody to okay that it's like safe to test your PR. And we also, it allows you to become members of some of our GitHub teams so you can be pinged on particular things if you're interested in in particular areas the project. You know as you continue growing you might become a reviewer reviewers are kind of our frontline as far as triaging incoming PRs, providing first levels of guidance as far as you know co correctness completion. All that kind of stuff and we we actually record in our owner's file section like who is reviewers for a particular area and who is able to kind of give that guidance. Continuing your undergrowth, you become the next step is an approver approvers are people who actually have commit rights to a repo. So the people who have approver rights over a particular part of the code it doesn't necessarily need to be an entire repo. But people have approval rights over part of our code base. They are people who are, you know, extremely trusted have lots of experience with a particular area of the code. And that we are delegating that like for that part of the code. You can actually do that final approval to say yes this is safe to merge and to tell our bots and automation to go and merge it. The top rung of that ladder is subject owner. So our subject owners are the people who are setting the kind of the vision for a particular area of code. They're the people who are who are coordinate kind of this larger like design architectural kind of decisions for that part of the code. They're also people who are going to liaise with other sub project donors other parts of the code base. So those are the kind of primary contacts for a particular sub project and making sure that it's running properly, as well as doing some of the reporting back to the special interest group that oversees that part of the code base. So this is very important to us because it shows that kind of growth pattern as we as we want to mentor people and grow people within the project. So that brings me to mentoring mentoring is essential to our overall project health. This is something that we can't say enough. So we've done things in contributor experience. We do things like administer some of the mentoring programs that span across the project, as well as facilitate and give tools to other six of like hey, you want to run a mentorship program. You, we have some of the best practices on how to kind of go about doing that and can help you out a lot. So a couple examples. I want to be respectful of time. So I want just going to skim through a couple of these examples. One of them is meter contributors. So meter contributors is like a live streamed ask me anything panel where we kind of gather some experienced contributors and people can submit questions and have these experienced contributors answer those specific questions. Sometimes it will have like experts from a particular part of the code base that you can engage with those experts, or sometimes it'll just be like general questions about like how did you get involved and, you know, I want to get involved in that same part of the project you are working on what where's a good place for me to get started. Those are like very common things that come up when we bring those those experts in. And another one is, is like we, we do things like Google summer of code and outreach interns where we can support people. You know, not just getting involved with the project but also being able to work with these programs provide financial support for for new contributors who are who are engaging with our project to help us out on like very specific guided projects, and then receive support for So, next in mentoring is our new computer workshop. So this is kind of undergoing a little bit of shift now formerly we used to do this as like a full day in person workshop at our contributor summits. But we're shifting it to make it a little bit more accessible to people because not everybody can come to a conference, especially nowadays. We're shifting it to be a little bit more peace feel a little bit more self guided and online so that it's people who want to get involved can get that kind of like one oh one level detail as far as how do I pick a sick how do I submit my first PR how do I, how is the project going to be focused in such a way broader than just any one particular sig is that you're kind of coming in with that base level of knowledge to hopefully be successful in your, your contribution journeys. So, again, I'm going to kind of skim through some of these things. So like in front we have this huge community of users and contributors on our slack instance, but 140,000. So we built some tooling and automation to help us out with that, being able to have folks report messages up to our moderator team to make sure that it's a safe inclusive space to do things like, you know, allow self service for creating and breaking down slack channels. As well as do things like submit announcements like we want to put an announcement out to a specific group of channels, we can do that in kind of one one swoop. So with that, I'm going to hand it back over to Allison. Thank you very much, Christophe. So we looked at what contra vex does and the different kinds of sub projects in the six. So now let's try to understand how you, you in the audience audience and you watching online can get can get right and like jump in and start contributing to all these many sub projects. So before I talk about the more about this first things first, I want to call out that no matter what people are the center of Kubernetes like everyone who's like, you know, out here supporting like everyone here like you know people it's all what makes it happen around here. So especially for this SIG, it is our mission to make contributing to Kubernetes easier and to ensure we have a diverse and sustainable contributor base. So let's see how you can get involved. So I really recommend as a good starting point you can join SIG meetings so SIG meetings help you get an idea of who is who, what is what and what kind of the context and what people are working on. So if you join the SIG mailing list like I mentioned, like you'll automatically get an invite for the SIGs weekly meeting. So to ensure meetings stay accessible for people around the globe contra vex has asynchronous meetings on Slack every alternative week too. So if you and as well, if you miss any meeting, don't worry, they're all recorded on YouTube. So, and even I myself, you know, there's only so much time in the day and even though I'm present at most of the zoom meetings. So I usually go and back and watch watch them again so I can make sure that Oh, is there anything like you know we missed out and meeting notes or like is there anything like I didn't really fully kind of grasp at the time. So with that, when you join a meeting, we're going to go to sorry. So, so with that, here's a couple tips on, you know, joining your first SIG meeting. So when you join a meeting, like, especially if it's your first time, like, you're going to feel, you're going to feel a bit overwhelmed. So there are so many people having discussions about things that you might not be that familiar with. And nothing might make that much sense at the time. So my advice in this case is to just take it slow. Like don't rush it and don't try to understand everything in one go. Look around and try to get an idea of who is who and what they're working on. So understand the broad ideas behind the tasks that they are working on. Like, for instance, I myself like, I'm working on the election side of things. So, you know, things like that and understand like, you know, the things happening in the background. And in the meetings, people be mostly talking about current tasks or making plans about what what should be done next. So keep an eye out about those and try to understand what's on the roadmap. This makes the information digestible and helps you not feel incredibly overwhelmed with everything. Now, another thing, like, we usually ask if like, there's anyone new on the call or at the start of the meeting, we say, if we like notice there's a bunch of new people, we'll try our best to say, do a round of introductions. Because I can find, if you're new to a community, it can be very overwhelming to raise your hand up and say, oh, hello, I'm here. I want to do something. So, yeah. Another thing about with these sick meetings as well, usually at the end of the contrabex one, we have time for just chatting just questions and answers. So if you've got like something that you want to bring like, how do I where do I get started? Or like, you know, can you recommend me a good issue or something or some way to look at something for them to look out like. Yeah, that's a it's a really good entry point. So next slide. I'll wrap this up quickly. There's also plenty of non code related paths available. So for instance, we have, you know, the stream teams like administrator and highly active contributor marketing team. So you don't necessarily need to know how to contribute to our SIG. So finally, if you want to reach out to us, you can find us on GitHub and on the Kubernetes slack at these handles. Our homepage has also has all the details and more that you saw in this presentation. So I look forward to seeing you on the contrabex mailing list and in the slack channel and maybe even in one of the zoom meetings. So I really hope you take this all in and, you know, decide and that contrabex is for you because come contribute to my SIG. Come contribute to our SIG please. Thank you for coming. Thank you for coming. I really appreciate it. And yeah, do we have time for Q&A? We might have a couple minutes for questions. Four minutes. So do we have any questions in the audience? I'd like to know if this year that you have some projects that are included in all Richie because I applied for all Richie but I was trying to look some projects for Kubernetes to contribute but I didn't see any project. I'm not entirely sure. So the way contrabex works with Outreach is we kind of coordinate our work with the between all the different SIGs in the project. So the different SIGs kind of come to us what we do kind of a call like hey if they know we're coordinating this year's outreach programs and that kind of stuff. So we put a call out to SIGs to understand if there's anything that they want people to work on. And then do that every so often. We have something inside of contrabex because with outreach you want it to be like a very clearly defined project that has like a very good scope of beginning and an end and all that kind of stuff predefined. So sometimes contrabex has that and contrabex will put in for something I don't think we have anything from us right now, but we also coordinate with the other SIGs as far as like making making sure that like that they they know like what what the deadlines are for SIG and helping them kind of like put applications together to start outreach programs. So I don't know of anything off the top of my head right now. But the very common answer that you'll hear for most of this stuff is come reach out to us in the SIG contrabex channel on Slack for anything that I don't have like a full answer to right now. And we can kind of pull pull that together and see if there there there is something. What is a technical lead. So what is your role specifically. So, there are two clearly defined governance roles that all SIGs have there and it's the chair and the tech lead. The tech lead like my primary responsibilities are doing things like when we have applications for like new sub projects for the SIG, Nikita and myself who share this role for contrabex. We kind of we look it over we make sure that it kind of works with our SIG charter and the things that are defined make sure that it's something that our SIG is explicitly responsible for. And then we kind of approve the creation of that sub project or trying to get it refined. We work with other tech leads for for other SIGs to do that kind of same roles if there's like the scope is not clearly defined and trying to like do some interpretation of the charters and also working with the steering committee in that regard as far as making sure that you know the right thing lands with the right SIG. And the other thing is we are a technical escalation point within the SIG. So if a particular sub project either doesn't know whether something is kind of the right direction. As far as our overall direction and vision and where we want to go for for the project. We kind of act as a technical escalation point for that. So it can be sometimes it's really big things. Sometimes it's really small things, as far as making sure that like a contributor flow, you know, as far as adding a label to repo and what that looks like like does that, making sure that we kind of understand the impact of that particular action on the contributor workflow and making sure that it aligns with our charter and kind of our established practices and that kind of stuff. Thank you for your out of time. Thank you very much once again. Thank you. Thank you so much for coming. Thank you.