 Hello, everyone, and welcome to this intro to CIG, Kubernetes CIG Contruder Experience. We are one of many special interest groups within the Kubernetes project, and in this talk we're gonna go over a little bit about who we are, what we do, and how we do it. With that, I'm Bob Killen, Co-Chair of CIG Contruder Experience. Alongside me, although not listed here, is my co-chair, Allison, and I am based out of Minnesota in the United States, and I work for Google. Also in the project, I'm a member of the Kubernetes Steering Committee, with that. Hello, everyone. My name is Christophe Lecker, and I'm a technical lead for CIG Contruder Experience, along with my colleague, Nikita. I'm based out of British Columbia, Canada, and I am also a member of the Kubernetes Steering Committee. So no matter how you slice it, the Kubernetes is a extremely large project, and at the core of it, it's the contributors that really bring our project to life. So of all the numbers that we're showing up here about activity and size of the project, that's the one that I really wanna draw your attention to. So who is Contruder Experience? What is Contruder Experience? Summed up, we are a cross-cutting special interest group that focuses on the experience and workflow of all contributors to the project, both experienced and brand new. We're made up of folks of different backgrounds, companies, and interests, but all with 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 CIG. 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 CIG that is more closely tied with the specific part of the project that they're interested in. Okay, but like, what do you do? Well, most other CIGs are focused on a specific part of the project. Contruder Experience spans the entire scope of Kubernetes and how folks contribute to it. We interact with contributors of all levels, both those just starting out with us and who made any 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, providing consistent guidance for folks. We strive to give contributors a consistent experience across the entire project, no matter which CIG or piece of code or documentation you're interacting with. Like any CIG, we have meetings and details about how to reach us on our contributor site. No matter which CIG you're wanting to get involved with, this is the great first place to go and look for information up on kates.dev. So now, let's talk about how we organize our work. With the size and scope of the things that we do, we've established some teams of folks to help us organize the bits and pieces. For example, we have folks like our moderation teams that keep our communication channels and mailing lists spam-free, or we have our contributor comms team that helps communicate out information to that large contributor base. We organize the work that we do into various sub-projects. These allow us to split things up and delegate work out. Some examples include our contributor site and community repo, which house details like the central siglist and our community calendar, or our mentoring sub-project that organizes our mentoring cohorts to build existing contributors within the project. So now that I've explained a bit about the type of work we do and how we organize, let's dive in a bit to some of these sub-projects, which will give you a better picture of what we've been up to. Swap again. I'll pick things up with community management. So in a project like Kubernetes, that is literally, you know, at this point, a medium to large-sized business with 70,000 contributors, there is a lot of things that go into sort of just managing how the community operates. That really starts with our mailing lists and calendars. Both are kind of awful, to be honest, but we try and make it as easy as possible. In Kubernetes, we have over 100 different mailing lists and oodles of calendars. The mailing lists are generally places to ask questions. We use them to facilitate decision-making. We share out meeting notes and all sorts of stuff to them. You can actually join the... Like, if you join a six-specific mailing list, you will automatically get access to all their calendar invites, their notes, and a whole lot of other stuff. One sort of funny thing, we've actually been... We've been using, like, the public Google groups for a while, but because we have now gotten so large, we cannot send calendar invites to them anymore. So we're actually in the process of migrating off the public Google groups to managed ones under the kubernetes.io domain. If you happen to subscribe to the mailing list, you might have seen the migration late last year to, like, dev at kubernetes.io instead of kubernetesdev.googlegroups.com. Transparency is also important to us. So all those meetings I was talking about that you can get access to by joining the sick mailing lists, we publish them to YouTube. We also have all sorts of other stuff on YouTube from, like, code walkthroughs, sort of, like, focus things on, like, recordings from the various contributors, summits that we do, other things on how to debug test flakes, two random, sort of, community things, like a giant three-hour-long bake-off that we did. That happens to be, like, the number one video on the channel right now, back in 2020 for our contributor celebration. We are also stewards of the community repo, and this is sort of the meta-meta repo for kubernetes, where we store all our things like our governance documentations, our election procedures. You'll find our values and code of conduct, and this sort of is the, like, I don't wanna say, like, sort of help desk for the project, but, like, it's where issues are opened up and things that sort of impact the community as a whole. We also have, with all those different teams, a whole slew of Zoom licenses, and managing it is kind of a challenge. One of the things we've actually had a lot of issues with on the sort of piggybacks and the whole transparency thing is going, like, automating the pipeline from Zoom to YouTube. Otherwise, it's all kind of manual collection and not so much funness. If this is something you have experience with, please reach out to me. We could use your help. Other things we do is we manage, we actually have, like, an instance of discourse called discuss.kubernetes.io, which is sort of our end-user focused community forum. It's where you can go to, like, ask general questions about how to, you know, use Kubernetes or problems with your deployment. We try and focus stuff there instead of in GitHub where we have far too many issues. Now, across all these platforms, we also have a slew of moderators that sort of just help our community safe. We have, in the root of the, not root of K community, but, like, in the K community repo, we have a list of moderators that we try and make sure we have staffed across at least the majority of time zones, so that way we can rapidly respond to something. Now, we've sort of tackled the community part. I'll tackle the next sub-project, contributor comms. This is also formerly known as the, like, marketing sub-project under Kubernetes, or under SIG Contrabex. So you heard about all those different communication platforms. With so many different platforms and outlets, it can be challenging to actually, like, reach out to our contributors. So we actually have an entire team that is essentially geared towards reaching out to our contributor base and making sure that they are aware of everything going on in the project, helping raise up areas of need, and just, like, you know, also talking about the areas that we're doing really, really well. Like, they're the ones that manage our public Twitter, Kates contributors, as well as publish a whole set of, like, blog posts across the main.io website and kates.dev. If you want to learn more about that group, I highly recommend checking out the, that talk from Kupon North America 2019. Next, we have our contributor doc sub-project. And as, pretty much like all developers do, the first thing they go to as I'm just trying it is the docs. So we have sort of a set of docs that cover two broad areas, and that's our contributor guide, which is sort of the general how to get on-ramped into the project, how general processes go. And then we have our developer guide, which tends to be very specific docs for how to contribute to certain areas of the project, API conventions, testing best practices, and things like that. One big thing is that these are living documents. Sometimes they get out of date. If you happen to find something out, please open up a PR and update them. We really appreciate that sort of thing. One other thing we are actually trying to do is consolidate a lot of this information down into an actual new contributor course that'll be like self-paced and hosted on our contributor website. There, we published a lot of this stuff, too. To pass it back to you. So another one of our sub-projects is our event sub-project with the return of in-person conferences. There was also a return of the Kubernetes contributor summit co-located with the event. This Monday's event had 140 people registered. We decided on a conference style of meeting due to uncertain attendance and staffing and that kind of stuff. But it was actually very well attended. We had a bunch of different topics that we got some good feedback on, and folks talking about ways to improve the projects, specific areas like Gateway API, or much more general topics, like how do we sustain code quality across a very broad code base. GitHub management. So this is another sub-project within us. We have, based on the size of the project, the number of repos, the number of organizations within GitHub. We have quite a large footprint that requires a team to manage. The team has done a lot over the last year. A couple kind of key things. We swapped our CLA system. We used to be on a closed source system that was not very flexible. We couldn't really figure out some bugs in it. There's very few people who had access to be able to triage things. We moved over to EZCLA, which is a new open source Linux foundation project, which will hopefully speed up that process of both identifying and fixing bugs in our CLA system, as well as making the whole process more transparent with more people having access. We added a couple new GitHub admins, Arno and Nebroom, who've been helping out scale our processes. We get a large number of requests for membership to our GitHub organizations, as well as requests for new things like repos or integrations and things like that. So we added a couple new GitHub admins who are able to help streamline this area, and we're going to continue with further improvements in the process there. So the next area is mentoring, but I want to go a little talk for a second about a prerequisite before I get into what the mentoring subprojects are like. So this is our contributor ladder. So we use this to kind of track and talk about the journey of a contributor as they join the project, start contributing and move up through the different levels of trust and collaboration in the project, getting more abilities as well as new skills along the way. So you start as a non-member contributor, just opening PRs. Anybody can open up a PR against any part of our code base and contribute. Once you've been around for a while and you get more familiar with the project, you may get a couple sponsors and apply to become a member. So that gets you some bonus things like your tests will automatically run. You don't need to ask somebody to start your tests running. After a while, again, building trust, you'll move up to be an official reviewer for a part of the code base and then eventually a prover, which will give you commit rights over a specific section or part of the code base and maybe eventually even into a subproject owner section where subproject owners not only have direct control over the code but are involved in discussions as far as setting architectural direction and making sure that a part of the code, a piece of the code base, like, for example, the kubelet is well-staffed and has what it needs. So for many, the biggest hurdle is going from either a non-member to a member or from a member to reviewer. So that's where a lot of our mentoring programs come in as far as building folks up and getting them connected within the project. We have group mentoring cohorts that are usually specifically focused on a specific area or need within the project where a small group of folks, maybe like 10 or 15 folks, will be mentored with the goal of some of them becoming a reviewer, becoming a member at the end of the cycle if they stick with it. So our mentoring programs are very, very important to us but we've also needed to scale back some of our programs. So we used to have some programs around Google Summer Code and Outreachee. We've needed to scale those back just a bit because we don't necessarily have the same resources. So we're looking at something we're actually talking about with our community is we need mentors. We need people who are already in that maintainer role to kind of help build up new contributors and to be able to assist in building other folks up in the project. One more thing I want to touch on very quickly here is shadow programs. So more and more SIGs are adopting shadow programs where if a person is in a specific named role like a chair or a technical lead of a specific group or the release team has a shadow program as well, different areas of the project where it's like you have a set role and a set responsibilities and you'll work along with the person who's actually holding that role currently to learn about it with the eventual goal of being ready to take over that role yourself and have some succession within the project. Another kind of critical area. And one last subproject I want to talk about is our Slack infrastructure. So we have a Slack instance of about 150,000 people. It's one of the largest Slack instances out there. It is. It's the largest public Slack out there. And Slack as a tool is great, but it's also not designed as like a public tool in that way. So there's a lot of things that they don't necessarily have like moderation tools. They expect if you're using it in a corporate environment and you have a problem with somebody, you'll go and talk to a manager or HR or somebody to help deal with that. But in our case, we need a moderation team who's able to respond to issues. So we built some tooling around it. We have moderator robots. We have bots that can send announcements to a bunch of different channels at the same time. We also have things where we, new people will come into our Slack and maybe won't necessarily understand the culture, the values that we're trying to drive within Kubernetes. So we have things like even a word suggestor where if somebody says a particular word, like one of them, for example, is if you walk into a channel and say, hey guys, the bot will like privately message you and nudge you and say like, hey, maybe here's a suggestion of a better term to end up using to adapt with the kind of culture of openness and inclusivity that's very important to Kubernetes. So we want to make it a safe space for everybody to be in and contribute and try to educate folks as far as our culture is. Back to you. So touched on this a little bit throughout the presentation, but a few things on how you can contribute to the project. Well, it contributes. We sort of, yeah, we went over a lot of the little stuff and one thing I do want to show is that we need people with a whole variety of different skills to help and grow and sustain, not just contrabex, but the project at large. This means people that are, you know, tech writers, people that are like project managers. So the project really needs a lot of project managers right now, but there's a whole, you don't have to be a programmer to be able to contribute to the project. Now, no matter what, the people are the center of Kubernetes. It is our mission to make contributing to Kubernetes easier and to ensure we have a diverse and sustainable contributor base. So how do you get involved? First big thing is join the SIG mailing list. That's when you'll get the meeting invites. Join Kubernetes Slack, join the SIG Slack. You'll be able to find this list of them and like the Kubernetes Community repo if you want to join the SIG-specific ones. Otherwise, just kind of browse around, though there are like 500 channels, so maybe not to the best suggestion actually. The other thing is most SIGs actually reserve time for new people to introduce themselves. Co-chairs and members of Kubernetes are usually on the lookout for new people to sort of help make you feel welcome, help you with finding work to do in the project, direct you to help on it or good first issues, and sort of shepherding you along the path. So a few little tips if you want to join your first SIG meeting. We'll usually ask if new contributors are on the call and we'll do like a round of introductions. It's sort of the easiest way to like get started with everything. If you are a little like, if you're just sort of like watching, one of the best things you can actually do is take notes. We're always looking for note takers. It's always an appreciated role. The other thing is, as I said the other day, and like the crew is steering AMA, open source is done by the people that show up. So attend regularly and you will honestly be on the fast track to becoming like an org member and being a part of the community. Volunteering for this stuff is pretty easy and there'll be people to help you along the way. Well, I started on this earlier, but there are non-code related paths and opportunities to get involved. Again, I called out like docs and PGMs, but we also have like our contributor comms team. They're the ones that are helping manage all the comms. We have a lot of various places where you can get involved and help just like speed through process and things like that. So last thing, if you want to reach out to us, that's our like GitHub handles within there. Most of us are also like available across Twitter, Slack, all that other fun stuff. You'll be able to find us all over GitHub. You can read more about us in the K community. Read me for SIG Contrabex. Join the mailing list, join Slack. And I hope you, you know, wind up joining and have fun in our SIG. That, great. So I think that's about it. We do have a few minutes if anybody wants to ask any questions that we might be able to answer. A bit on the shadow programs that you have. I know release has one shadow program, but what about other shadow programs? Like now shadow programs have been a part of one, but I think, I don't know if there are many shadow programs in the six. So the question was about shadow programs and where they are in the community. The main one being the release team. That's probably the most well known. I know docs has done a few. We are actually talking about implementing some and SIG Contrabex experience. There's a couple other SIGs that are, you know, just starting to approach this idea. I will say like a lot of, a lot of the SIGs don't have shadow programs out yet, but are interested in getting started. More are starting with the whole mentoring cohorts idea. And I think that might wind up in it, evolving into a shadow program. Yeah, and there's a few shadow programs that are maybe not even like known by a shadow program, but it's still a very similar thing. Like for example, our security response committee has like an associate level within it where they bring folks in and get them started on like triaging bugs and security issues that are public already so that they can get experience and understand like what the security response process is. Yeah, there's a number of groups that have introduced something similar to it. Where shadow programs really shine is where SIGs have named roles, which is something that we're encouraging and a lot more SIGs are taking us up on as far as defining here's a particular role. Here's a like a run book for that role so that people know what are my responsibilities? What do I have to do? Even how long I have to do it for and rotating folks through a lot of those things that have been fairly successful at SIG release, a lot of other SIGs are looking to adopt similar things. If you go to the ladder of the contributor, there was from going to the non-member contributor to the member contributor, this is the step of sponsored by two reviewers. What does this mean and how does the review process for moving up the ladder works? So the question was going from a non-member contributor to a member, how do you end up going about getting reviewers? What is getting to like sponsored by two reviewers mean? So when you're looking to kind of get sponsored, the idea there is we want you to go and talk and make relationships with the folks in the project. We want them to be able to see your contributions and to see not just a one-off PR here and there, but the idea is that you are somebody who's contributing a couple different things and you're having conversations, you're showing up to SIG meetings, you're actively participating in some way. The criteria for being a reviewer, there is a defined document in the community repo that says who is a reviewer, what is that criteria to figure out who it qualifies but typically if you're opening up PRs and they're getting reviewed, whether they're in docs or code or policy or any other part of our project because all of it exists in GitHub. If you're opening PRs for that kind of stuff that if you're speaking to the people who are actually reviewing and merging your things, those are the folks who are typically eligible to sponsor you. One of the other key things there is just to make sure that we have neutrality in the project and that you are, again, talking to folks. Your sponsors cannot be from the same company and the idea there is we don't want there to ever be a part of the project where it's like, oh yeah, I'm employed by X company. That automatically gets me rights into the project. No, that's not the case. You need to build relationships not just inside your company but with other folks in the community. Bob, do you have anything to add to that? No, you pretty much covered it. Cool. So if you were leading a SIG or a working group and we're interested in mentorship and shadow program and those kinds of things, what kind of roles? Surely you may not have a shadow program for a chair but you mentioned name roles. What does that look like? How could we integrate those kinds of programs? Funny enough, we are thinking of shadowing for a chair. Well, let me repeat the question. As someone that's heavily involved in a SIG sub-project or a lead, how do you approach creating named roles? How do you approach mentor, cohort type stuff? And we are actually thinking about several SIGs including actually KintrubEx are thinking about doing shadow type roles for our SIG leads. As far as the other named roles, it's usually trying to think of something that is done frequently or a set of skills that are done regularly and think of a job description and scoping that to a role and then potentially binding it to a certain period of time where it's like, okay, someone's gonna hold this role for a year or two years and then it's their job to either potentially hold it again or think about finding someone else to take over that role. This is sort of the idea of having terms associated with it. And there can be more than one people in that specific role. We've seen this with release managers and the whole release manager associate program. Docs has several roles. The API reviewers and API reprovers, those are great, the production readiness review is another great one. Bug triage is also a common one that a lot of different SIGs have, like some sort of rotation of who's gonna triage the incoming bugs, identify things that are duplicates, identify things that are actual real bugs or things that are expected behavior and we can just close the bug because it's not actually a bug. Another one actually that I talked to a couple of people about was actually having SIG-specific CI signal roles. So you basically have a person that's watching that and can raise those issues in the regular SIG meetings. There's lots of ways to think about it. The best way when a SIG is thinking about this and talking about how to define those roles is to make them small, scoped, and very well defined. Something like a CI signal role, for example, or a bug triage role. They're roles where you could have it be where somebody triage bug picks it up, goes and fixes it, closed the bug, the entire lifecycle of it, but usually that's way too much, especially with the volume of things coming in. So scoping them smaller and more closely to what it is where it's like, okay, my only job here is to just triage it and then I can rely on the rest of the SIG and other folks to come help do the actual fix. Things that are very helpful. By keeping it small. Yeah, definitely. I think we are actually out of time. Five more minutes. Five more minutes? Yeah. So does anyone else have questions? Why not? We have five minutes. So I know about Google's amount of code and outreach. They are good programs. They're good programs for students. It gives you a quick kickstart. But these programs, I don't know if they're more suitable for professionals. I'm not a student and I've participated in GSOC before, so I cannot do it again. But I want to contribute to Kubernetes. You know, there are a lot of things I could do, but sometimes I'm not motivated enough, but I'm wondering if there could be some programs for professionals as well or non-student, which are kind of like GSOC or Outreachy where you have a mentor, assignment it and you can work on a specific issue. I'm not sure if I'm making sense. I'm just thinking out loud. So the question was things like GSOC and Outreachy are really targeted towards students and getting started. There isn't really a program out there that targets people that doesn't necessarily apply to, potentially people that are out of college already sort of in the field, but are looking to start contributing things. I do believe the LFX mentoring program does apply. The big issue with a lot of those programs and one of the reasons why we've kind of put a pause on Outreachy and GSOC as programs, they're very energy intensive because typically those programs are like assigning one mentor to one mentee and then they're focused on a particular project. There's definitely value to that, but it requires a lot of maintainer time, which in our current state where we're like we're having problems finding maintainers and maintainers are getting burned out. That's why we're focusing on some of these programs where it's a group mentoring, where instead of a one-to-one, it's a one-to-end kind of relationship. We're mentoring a group of people to try and all build them up into that same role in a much more general way as opposed to a mentor mentorship program where it's like a one-on-one relationship for a particular project. They definitely have their place and they're very high value programs and we've had tons of phenomenal people that have gone through those programs in our project, but they require a lot of maintainer time and energy. Okay, I think we have time for one last question if anybody has one or we'll wrap it up there. Okay, great. Thank you so much for coming.