#74 October 8, 2019

Community and Contributor Experience, with Jorge Castro

Hosts: Craig Box, Adam Glick

Jorge Castro is a community manager employed by VMware to help keep the Kubernetes project running smoothly. He joins Adam and Craig to talk about the programs run by SIG Contributor Experience, the difference between supporting contributors and end users, and the recent steering committee election.

Do you have something cool to share? Some questions? Let us know:

Chatter of the week

News of the week

CRAIG BOX: Hi, and welcome to the Kubernetes Podcast from Google. I'm Craig Box.

ADAM GLICK: And I'm Adam Glick.


ADAM GLICK: I hear you had the good "luck" of seeing a concert this week?

CRAIG BOX: I did. There's a fantastic New Zealand band that defined rock through my childhood, The Exponents. And their lead singer is a guy called Jordan Luck. And he's doing his own thing with, basically, a cover band, which is just performing Exponents songs and other great New Zealand hits called The Jordan Luck Band. And because there are enough Kiwis in London to justify that, they came to London and played a great set.

I would say that the guy is famous for not being able to sing very well on the stage environment. And he didn't let us down, but it was all in all a good performance. There's some videos on my Twitter account if you're interested. And if you're into New Zealand music at all, you absolutely should follow me because I post little videos like that all the time.

ADAM GLICK: Awesome. This week, we've been doing some Halloween shopping, preparing for the upcoming holiday. And as well as getting costumes, we were thinking about what we're going to give out for trick or treaters. We decided we didn't want to give out candy. And so I'm sure to the great dismay of the kids that come by, but the joy of all the parents that will be with them--

CRAIG BOX: It'll just be hugs.

ADAM GLICK: [LAUGHS] Oh, yeah. We'll be giving out self-inking stamps. We were deciding what can we give out that might be nice. So we decided on that for this week. And that's been our fun as we prepare for Halloween, which is always a really exciting holiday around here, especially if you've got little ones.

CRAIG BOX: Did you have one custom made?

ADAM GLICK: We did not. We got a bulk pack provided. You can order them. And they're not very expensive to get, and just something to inspire kids and their creativity.

CRAIG BOX: Perhaps we'll check it out for KubeCon? Stickers, they're so last century. We're going to give you a little self-inking "Kubernetes Podcast" stamp. If you're interested, write in and we'll make it happen.

ADAM GLICK: Let's get to the news.


ADAM GLICK: The Kubernetes Steering Committee elections results are in. The four newly elected members are Christoph Blecker and Derek Carr of Red Hat, Nikhita Raghunath from Loodse, and Paris Pittman from Google. They join the three existing members of the steering committee, Aaron Crickenberger of Google, Davanum Srinivas and Timothy St. Clair from VMware, to form the final seven-member group.

This wasn't just any election, though, as this election signifies the full shift to all steering committee members being elected by the community with the rolling off of the previous bootstrap committee members. Election for the three seats that were not filled this time will be held next year, with each of the elected seats holding a two-year term from now going forward. Congratulations to all the newly elected members of the steering committee, with a hearty thank you to the previous committee members for all they have done to help Kubernetes get to where it is now.

CRAIG BOX: The CNCF has released their second project journey report, this time for the Envoy proxy. The report highlights the growth of Envoy, including a 600% increase in project contributions since joining the CNCF. They also highlight that although the project started at Lyft, and Google is currently the largest contributor in both total code and current volume, there are 176 companies involved, with over 1,700 individuals contributing.

ADAM GLICK: StackRox has announced their latest update to the StackRox security platform. This update includes integrations with security information and events management tools, including PagerDuty, Splunk, and Sumo Logic. The offering is now available in all major cloud marketplaces, as well as for Google Cloud's Anthos. The update further provides integration with Azure Container Registry and provides support for Google Cloud's container optimized OS. Finally, this release supports EBPF instrumentation, as well as the Istio service mesh.

CRAIG BOX: StackRox also posted a warning about a Billion Laughs attack possible against the Kubernetes API server, so named for the sample code which expands the string lol into a billion lols, taking up 3 gigabytes of memory. Fixes for this are due out any day now, but until then, StackRox has taken the opportunity to remind people to lock down their Kubernetes resources and suggested some security best practices.

Review your RBAC policies and limit access to required resources, audit your clusters and roles on an ongoing basis, turn off anonymous authentication, and do not expose your API server endpoint to the internet.

ADAM GLICK: Heptio open source projects Velero, Octant, and Sonobuoy are moving under VMWare's new Tanzu brand on GitHub to remind everyone their commercial product is grounded in open source. The Heptio brand is going away, and other projects are slated to move over or be deprecated this month.

CRAIG BOX: Contour, which also started life as a Heptio product, but sits in its own GitHub org, has launched a beta 1 for an upcoming 1.0 release scheduled for KubeCon in November. The biggest change is the renaming of the IngressRoute object, which was introduced as the CRD to provide functionality perceived as missing from the existing Kubernetes Ingress. In order to clearly distinguish between concepts and prepare for a stable release, the object has been renamed HTTPProxy in this beta. It also adds two new concepts, inclusions and conditions.

ADAM GLICK: Salesforce has released Sloop on GitHub, a tool for visualizing the history of objects in a Kubernetes environment. Sloop lets you look at objects which no longer exist, like pods from previous deployments, and shows events over time on a graph. It's a 0.1 app and requires compiling from source, but it looks to have potential.

CRAIG BOX: Kontena has announced Kontena Lens, a free desktop application for managing Kubernetes clusters. Lens was previously a feature of Kontena's enterprise product, but has now been open to the public and is available for Windows, Mac, and Linux. It offers graphical dashboards for access to multiple clusters with the ability to open a Terminal window and use kubectl built in. Access is still limited to their customers, but the public can now request access to Lens through an online form on the container website.

ADAM GLICK: New Google Kubernetes Engine feature of the week-- if you have a private cluster where the master is not accessible from the internet, you can now configure the routing between on-premises networks and the cloud VPC to allow access to the master from on-prem.

CRAIG BOX: New Azure Kubernetes service feature of the week-- managed identities, a wrapper around Azure's service principles to cover the fact that each is provided with an expiration date and handle renewing these for you automatically.

ADAM GLICK: The folks at Ambassador have done some benchmarking of common proxies, and the results are probably not a surprise. They tested HAProxy, NGINX, and Envoy. The tests focused on the number of requests per second each proxy could handle and what the latency for each was. In general, Envoy added vastly lower latency, with numbers generally under 10 milliseconds, while NGINX and HAProxy appeared to have significantly greater latency spikes. Ambassador has promised to do additional testing and publish the results in the future.

CRAIG BOX: The CNCF has announced that they are looking for people to help run Kubernetes Community Days in locations around the world. Community Days are community organized events, similar to DevOps Days, that gather the community to learn, collaborate, and network to further the adoption and improvement of Kubernetes. If you're interested in hosting one, the CNCF can help support you with guides on running an event and tools to make the management easier.

ADAM GLICK: WeaveWorks, who popularized the term GitOps by using it a dozen times per post, have released two new pieces of Kubernetes tooling. First up is WaveWorks' GitOps Manager with 30 mentions of the term, which lets you configure cluster environments using the open policy agent and runs on top of any Kubernetes environment.

Next is WKSctl, a management tool for Kubernetes with a mere 20 mentions of GitOps. It is named to evoke EKSctl, the tool that WeaveWorks built and AWS made official because they couldn't be bothered creating good Kubernetes tooling themselves. WKSctl uses GitOps for cluster management using the Kubernetes Cluster API to automate installation of clusters using their open source flux tool, now a CNCF project.

WeaveWorks says that the model provides ongoing validation of your cluster to avoid snowflake clusters and make processes more repeatable and manageable. WeaveWorks GitOps Manager is available as part of their WeaveWorks Kubernetes Platform subscription service. WKSctl is open source.

CRAIG BOX: Finally, listener mail. David Young, FunkyPenguin, from New Zealand, a country you may not have heard of as it's famous for being left off maps. David heard Episode 72 with Lachlan Evenson and the challenges of updating APIs to the new V1 APIs, so wrote a script to transmogrify Kubernetes resources to the new versions. Quoting a snippet of our show transcript is a sure fire way to get a mention in the news.

ADAM GLICK: And that's the news.


ADAM GLICK: Jorge Castro is a community manager at VMware working on Kubernetes. Welcome to the show, Jorge.

JORGE CASTRO: Thanks for having me on. I appreciate it.

CRAIG BOX: Let's start a little bit with your background. Your bio says you spent four years in the Army riding with the 11th Armored Cavalry Regiment. Have you seen the latest John Wick movie?

JORGE CASTRO: I haven't.

CRAIG BOX: He's an assassin who's being chased by other assassins, and he manages to kick the front of a horse and then the horse's back legs kick out and take out the other two guys. Is that something you're trying to do?

JORGE CASTRO: I don't think so. There are horses. I never got to ride them. They're kind of there for ceremonial purposes.

CRAIG BOX: The cavalry is a little bit more mechanized these days, is it?

JORGE CASTRO: Yes, yes. If you've got questions about Bradleys, I'd be happy to help. Horses themselves, though, not so much.

ADAM GLICK: But speaking of previous experience, you used to work at Ubuntu for almost a decade. What was that journey like, as that grew?

JORGE CASTRO: I was there for a very long time. I was there for 10 years at Canonical. Before I was doing volunteer work, I worked at a university. That's kind of where I learned Linux, and back then, everyone's kind of spinning up on this Linux thing. And I ended up just doing a bunch of work there in the distro, and then the opportunity came to work there and do community stuff full time.

So I did that for a while, and the last few years was mostly cloud based, which is how I ended up in the Kubernetes community, as part of what Canonical was doing at the time. I would end up at KubeCons and I remember Tim Hockin's talk at Scale in California about what Kubernetes 1.0 looked like. And all the engineers I was working with were really excited about Kubernetes, and we were checking it out, diving into containers and that kind of stuff.

And that's how eventually I met Joe Beda that way and ended up at Heptio right after when they were looking for a community person to work in Kubernetes upstream. And I had already met a bunch of wonderful people, and even though Kubernetes is its own community, there are a lot of people here that I've known from other communities that ended up here as well. So I met Josh Berkus through his work at Postgres at the time, right? So you would end up running into a bunch of open source people. And as Kubernetes became more popular and people started working on Kubernetes, we all kind of ended up here, I guess.

CRAIG BOX: Do you think there's a finite amount of open source community people, and they're all just on this project at the moment? Or is this a part that we're effectively growing?

JORGE CASTRO: I think it depends on the generation. I'm kind of like the middle generation, I feel, post-Linux. Like, I didn't actually work on anything when the kernel was, like, starting off to be this huge thing and things like that. And then you obviously have people that are just getting started, but there's like a cadre of us I think that's been around. They've kind of seen large projects be successful. They've seen large projects fail. It's kind of an exclusive club is kind of the term I would not really use, but there's definitely people there that you know and bring expertise from their other open source projects that I think Kubernetes benefits from.

ADAM GLICK: I remember having a discussion with Sarah Novotny when she was talking about kind of the different groups within the open source community, of the diehards who are there because of the belief in free and open software, the people who are part of vendor communities as it's become kind of the Apache license has grown and there's vendor ecosystem around it. New people are coming and kind of contributing small pieces, using small pieces dipping their toes in the water. What have you seen as the change, kind of who the community is?

JORGE CASTRO: One of the things I've noticed, especially lately, especially in Kubernetes, coming from just a normal distro land, is a lot of the people that were involved in Kubernetes because they're higher up the stack, tend to not care about things that you thought were important at the time.

ADAM GLICK: Such as?

JORGE CASTRO: Like your Linux distro. Most people don't care. They're like, I need an operating system, and if it runs the kubelet, I'm good. Whereas before, I feel like in projects I used to work for were very much about the low level thing. Like, I have a really strong opinion on systemd, right?

But in Kubernetes land, they're like hey, as long as an OS is there to do its thing and the operator tells Kubernetes to unschedule itself so it can do maintenance, most people just tend to shrug. And I think now Kubernetes is kind of becoming that way itself a little bit, right, where it's like, you know what? I kind of don't want to manage my control plane and would prefer a cloud provider do it or something like that.

I think it's a good thing when people say Kubernetes is trying to get boring. There's obviously pain points that we still need to address, but I think as I've been moving from community, community, I kind of tend to have been moving up the stack, I guess, a little bit.

CRAIG BOX: As has the industry.


JORGE CASTRO: Yeah, exactly. So there's times where it's like the Kubernetes released notes might not be important to a lot of people, which I think is great.

CRAIG BOX: Joe and Craig started Heptio with that goal in mind of making Kubernetes easier to use and consume. What was it that made them choose to hire a community manager?

JORGE CASTRO: This is actually what brought me to Heptio. Joe had publicly mentioned in, like, a SIG cluster lifecycle meeting, hey, I'm doing a startup. If anyone's interested, check it out. And at the time, I was new. I didn't really know who Joe Beda was. I was like, there's that guy who has a really strong opinion on cluster lifecycle. And I didn't know it at the time that he's one of the co-founders and things like that. So I had heard of Craig McLuckie, and he was interviewing me for something. He was like, what I really need is like a community manager.

At the time, Sarah had kind of shepherded things through 1.0 with all the co-founders and everything. And he's like, well, we really want to show that we care about this, so we want to help Sarah out. We need someone who's going to do the role that Sarah did for 1.0 because obviously, people get tired. And by then, she'd been doing it a long time. So we're going to chip in, and we're going to show that we take this very seriously. And the community health is our priority.


JORGE CASTRO: So as soon as they mentioned that, I was like, this place is for me. I had known Sarah before through OSCON. If you'd spoken at OSCON at the time, you ended up meeting Sarah at some point. So when I talked to her, we both got really excited. And then I just showed up one day. She gave me a bunch of keys to things, and then she went on vacation.

CRAIG BOX: What did you find in the doors that those keys unlocked?

JORGE CASTRO: It was a lot, so back then, there was a lot of-- this is something that people who run open source projects, they ask for advice and stuff. There's like a bunch of vestigial stuff that people just set up without thinking, oh no, this is going to be successful in three years. And then we'll have to make sure that there's no bust factoring here and things like that.

So back then, it was like I was just directly added to the GitHub org admins and stuff like that. The way we do it now is actually kind of different. This is something we can talk about, is how the project has kind of moved towards more automation for certain things. So things like the GitHub org, if you're at the GitHub org now, you have an application. We have a little template you fill out. There's like a process.

On the pass, it was really kind of like, well, I've done enough merge requests. This person thinks I'm OK. OK. Now we're kind of doing it in a way that's like, OK, not-- formal's kind of the wrong word, but probably where it's like, OK, I'm going to start my Kubernetes journey at this step. After I do x amount of PRs, I'm going to go to a SIG. I'm going to find a sponsor. That person is going to mentor me. They're going to make sure I'm getting good reviews, things like that.

And we kind of outlined a set of steps for if you're new here and you want to get started, this is a good place to start, who to ping, as opposed to in the past, where it's kind of like just show up. So I mean, you kind of have to do that for scale, right?

ADAM GLICK: It sounds like you're going through how do you scale a community the same way that you scale a software project, from a few people working on it to literally--


ADAM GLICK: --tens to hundreds of thousands.

JORGE CASTRO: Yeah, and the community processes, they're the same as engineering processes, right? Like, for example, in the past, it was like, hey, I've got a cool Kubernetes project. Can you create me a Slack channel? And then we would look at it and say, OK, this looks fine. And then we would create it. Now we declare what our Slack channels are in a file. And anybody in the community could do a pull request on that.

CRAIG BOX: And then a controller comes along and defines those channels for you.

JORGE CASTRO: There is literally software that Katharine Berry wrote to just automate the whole thing. And it works out better for everybody, right? You have an audited set, auditable things of who created this channel, why, what was the reasoning, as opposed to, well, trying to find a community manager in Slack.

CRAIG BOX: They're all busy recording podcasts.

JORGE CASTRO: Yes. Now we can do podcasts and stuff, instead of making channels all day. But that's just a small example of if we automate these processes and have something like that, it lets a community be more self-service to itself.

ADAM GLICK: How do you define what mediums and channels are part of the community officially versus not officially? And how does the life cycle live for those? Is the Geocities page still there? Has it gone away?

JORGE CASTRO: So a lot of this is very much like vestigial stuff that somebody set up, right? Like the Twitter account Joe Beda created something, like, five years ago. A lot of these things we do share a lot of maintenance there with the CNCF. So the CNCF runs the Kubernetes Twitter account, and then we just ask them to tweet stuff. For a lot of other things, we've always just had them, right? So the Google Groups for the SIGs and things like that.

And then other things we've either tried to improve or become aggregates. So the YouTube channel just used to be an archive for all the team meetings. Now we're kind of trying to make it an active thing where we have an office hours program for you, or we do a meet our contributors live stream to kind of take advantage of the properties that we're on already.

And then there's some unofficial properties. Like the Kubernetes subreddit has, like, 30,000 people on it. But it's not an official avenue, but there are members of Kubernetes who are moderators there, so.

ADAM GLICK: Have you ever had to turn down a channel, that something was a place and then either that medium just lost steam or people were more interested in communicating through a different means?

JORGE CASTRO: The Kubernetes users mailing list, which had this really-- this is a tough one for me. Because it had a really long history. It was the original containers mailing list that predates Kubernetes that they just had renamed or something. And we were having a problem with spam on email, and the moderator tools and stuff like that were just becoming a bit hard for our SIG to manage, right? Where you could say, well, the developer mailing list, we can certainly moderate that, because that's a trusted set of people.

But as far as just a general mailing list, the amount of work and volunteers trying to find for moderators was just too much. So that's where the idea came, well, what if in a user and case like this, we can move that to a tool that allows the community to moderate itself, like Discourse, which is how we kind of ended up with discuss.kubernetes.io, the idea there being you have a place that gets easily indexed by search engines.

It's open for users. The more a user participates, the more they can kind of help moderate the site and were able to now run that site with very, very little input from us, right? Because the community generally does a decent job moderating itself if they're given the right proper tools.

CRAIG BOX: This isn't your first online community experience. You set up Ask Ubuntu, which is a Stack Exchange site. How long ago was that?

JORGE CASTRO: That was-- oh, boy-- whenever they started to really talk about stack exchanges. But at the time, there were only three, and it was Stack Overflow, Server Fault--

CRAIG BOX: Super User.

JORGE CASTRO: And Super User, yeah, yeah. And then very quickly, Ask Ubuntu became, like, the fourth biggest one. This was kind of like when Ubuntu at the time was kind of trying to reach for an end usery thing, as opposed to just only being cloud. So it was really popular. It was easily the fourth most popular Stack Exchange. And during releases, we would pass server fault traffic wise, which was pretty cool.

And I think for projects in the community, like I said, if you give them the proper tools, they'll help you do the things, and especially with technical information, the amount of out-of-date information on the internet, which is terrible. So launching something that lets users kind of maintain their own thing, I think, was fundamentally a good idea.

ADAM GLICK: How much of your job as a community manager is about helping grow the community versus helping manage the community?

JORGE CASTRO: This touches on an interesting topic, because when we say grow the community, our main topic, especially in SIG Contributor Experience, is, we want to grow the people that contribute. We need a healthy core of people, right? The project is not old enough where people have been working on something long enough that they start to kind of think about cycling out.

And our ability to onboard new people through mentorship programs or even if someone just wants to be a driver-- we have something like 32,000 drive-by contributors. Like, that's ridiculous. Right? Any number that you think, other than the kernel in Kubernetes, are just seem to be exceptions to every rule when you look at open source projects.

So we really do concentrate on hey, I'm new here. I have this set of skills. I need something to do. However, due to the popularity of Kubernetes, I feel like we end up kind of having this hope, but we really want to help our users as well. So our contributor experience, especially kind of we're having this, I don't know say existential crisis, but I've put together a proposal with steering that maybe there should be a separate special interest group in Kubernetes who is specifically targeting helping end users with forums, getting content on YouTube.

You see users self organizing around things like, how do I prepare for the CKA, if you look at Henning Jacobs putting together a list of Kubernetes failures for other end users to learn. There's all this stuff that's really, really awesome that we really want to do. But it's difficult for us because dealing with just contributor growth itself is our full time job, basically.

So I'm always kind of looking for people. I'm hoping that some day, someone shows up-- and he's like, I love doing end user stuff-- that could help us sort out how to drive our presence on Stack Overflow, for example-- Kubernetes has a tag on there-- and managing all these. It kind of ends up being in our wheelhouse right now. But I'm looking to-- split is probably the wrong word. But putting the right people in the right focus to help both groups is important to the project.

CRAIG BOX: Do you think that you can consider the Kubernetes community as a single entity, or is it better to think of the contributors and the end users as different groups and give them different sets of tools?

JORGE CASTRO: It's definitely one community. I think something that everyone has learned is separating your developer community and user community is a good way to write stuff that users don't need or want. However, the tools can be different. A Kubernetes user can sit in the Kubernetes community meeting and get a bunch of SIG updates. And that has nothing to do with how they consume Kubernetes, right?

What they might say is I don't understand what's happening with all these processes, but I'm glad that someone is doing this, right? They're smart enough to realize that this is important work. And I'm glad that these SIGs are doing this and that they're doing these Kubernetes enhancement processes. And I don't know any of that stuff, but it makes me feel better about using this stuff that someone's handled that.

However, I have a problem right now at work that I need help with because I'm consuming Kubernetes. And I think developers understand that. Like, when you see someone like Tim Hockin sometimes on a contributor mailing list, and be like, I'm too busy. Sorry I've let you down with this. But he still makes the time to go on to discuss that Kubernetes.io, and you see him answering questions, just to figure out what people are doing. Hey, what's your use case for this? This sounds really interesting. Maybe you can help with this one. That's encouraging. I've never run into a Kubernetes developer that hasn't really wanted to interact with users as far as getting feedback from them.

CRAIG BOX: As a Linux user through university and then afterwards that was involved in a local Linux users group, and one of the things that that group taught me is that you have people who come along and say, hey, I know nothing. And then you have people that come along and say, hey, this is my full time job. And you can't really run a single meeting that continues to keep the attention of both of those groups of people.

Yet, you need to have the experienced people in order to help the newer people move up through the ranks as it were. How do we keep that balance when we're not necessarily talking about the contributors versus the users, but the tiers of people who come in as new users and then the more experienced administrators at the other end?

JORGE CASTRO: This is extremely difficult. This is why usually when we ask SIGs are supposed to maintain a set of tags. Good dash first dash issue in GitHub is what it's called, right? And then sometimes I'll file bugs where I know a new person can do it, and I'll kind of file a template and I'll mark it a good first issue. And then I'll tweet something like, if you've got 50 minutes and you can do markdown, you can do this little tidbit here.

Ideally, in the perfect world, right, each SIG in every area would have a set of these. So if you're like, oh, I think I could do a little bit of networking today, right? And going to SIG networks, but do some submissions and then move on. But unfortunately, I mean, Kubernetes tries to solve complex things, right? So there are certain elements that you need to have that expertise. Like, if we have a new person who's like, I'm really interested in API machinery, it's like, ugh.

CRAIG BOX: They should listen to last week's podcast.

JORGE CASTRO: Yeah, I was like, that's a kind of tough place to start. But that's one of the things I love in our work about contributor experience is we kind of like to be the default home room for you if you're new, right? Show up here because it's what we call a cross cutting SIG, so it kind of is a horizontal slice, so we get a little bit of everything because we're working with a lot of SIGs. So the idea there is like, come to our meetings. You can find out about the project from a higher level, and then decide, OK, maybe I'll go to that networking meeting that interests me.

So sometimes we have people. They'll show up to two contributor experience meetings, and then they'll be like, oh, OK, I found the SIG I want. I'll see y'all later. And then, yay. Or they might not find anything and they might just think that I'm going to find the one thing I want to do and just do that. So this guy Pooya from Super Giant, he donates one hour a month to office hours, right? We hop on the live stream, and we try to answer as many user questions and stuff. It's fun. We give away T-shirts to people if they ask questions, things like that.

But it's nice that you can have one person just commit-- I'm going to commit one hour. This is the thing I'm going to do. And then we have a cadre of people like that, agile speed and a bunch of others, Chris McCarty, that all they do is donate their one hour a month to the project to help someone out. And as they've gotten involved-- now Chris is not involved with the release team because he starts to get addicted to the rush of working with a bunch of other people and things like that.

So usually I just try to tell people, if you could just find one thing, dedicate an hour to it. And then once you start to get to know the project, you'll start to realize where your time will be most efficient.

ADAM GLICK: When we first started the podcast, actually, Episode 1, we talked to Paris Pittman, and it was focused on the community. That's over a year ago now. And I'm curious, if you think about how the community has grown, not over the past year, but over the past several years, what do you think are the biggest changes? And you mentioned a little bit about some of the automation work and some of things you're doing to try and help scale that. I mean, if you could talk a little bit more about what you're doing to scale such a massive community.

JORGE CASTRO: They're simple things. I'll give you an example of something Paris did. When you have a sick meeting, someone records it and then they have upload it to YouTube and then do a thing, right? She set up some automation there, where the SIG person could just record the meeting, and then a little bot talks to the Zoom API through a service that we're signed up for. And then it'll automatically upload it to YouTube. And then the YouTube admin, my only job is to double check that it's on the right playlist, and I hit Apply.

There's a bunch of automation going around the bots and things like this. So you've seen this before, and it's end user facing because you file an issuer to a PR in Kubernetes. And then a bot tells you a bunch of stuff. So there's a lot of things you kind of have to do. It's because people are like, well, I don't want a bot talking to me. It's not a really great first experience for my Kubernetes journey to have a bot talk to me, right?

CRAIG BOX: Did you see there was a thread going around the internet recently about a commit that was suggested by a bot, approved by a bot, and then automatically thanked the bot by another bot?

JORGE CASTRO: Yes. We have these jokes of, like, we have some issues in the past where it's like the bot talking to itself, and it's like, what's happening? But you kind of have to have them. Like, people have to sign a CLA. We have about 1,000 open pull requests at any given time, and that number has always been around 1,000 in the 2 and 1/2 some years I've worked here. And the developer velocity is actually increasing as well. So it's not like they're not landing this stuff.

So for a lot of these things, you have to have automation, and even though, yeah, I would love it if I could give you a personalized message for every pull request kind of thing, it saves everyone's time when a bot can remind you to go check your CLA, instead of having people wasting actual people review time to do that. So there is a lot of automation happening there. There's a lot of automation happening around release that the release team has been doing slowly over time.

There's like an entire actual working group called Kubernetes Infrastructure, [wg-]k8s-infra, that is doing a lot of this stuff because we have the intersection with the CNCF as well. And it goes all the way through to, like, how do we publish binaries and all that kind of stuff. Over the past year, I think a lot of automation has been in place, but there's never a shortage of work. So some days, it feels like we're still treading water.

ADAM GLICK: How do you pick the technologies to do it? So obviously, with things like Kubernetes, people write and go. And that kind of solidify with the project. But when you're talking about the community, you mentioned that you were using Zoom for some of the meetings, YouTube for posting them, you had groups, there's a Slack channel-- there's many Slack channels. How do you choose which ones? From the list of them, clearly, not all of them are open source. So how do you manage those two pieces?

JORGE CASTRO: A lot of these existed already. For example, we do use YouTube for archiving and things like that. And then I broadcast when we were doing our live streams and our office hours and things like that. But we do talk about, especially around the YouTubers, have we tried to do a live thing on Twitch, just to see what it's like? It's a slightly different audience. Is that like a cool thing we could do?

So I'm kind of constantly always looking at different tools and things like that. I don't think we've ever said we don't use these things because it's a SaaS. I've also seen projects in the past kind of restrict themselves to only free and open source tools. But I don't think our project should run a Kubernetes cluster with all of our self hosted stuff. We've got enough stuff to do.

So I think, generally speaking, when we look at tools, we look at things like moderation. Obviously, if there's a free software-- like, there's nothing out there that competes with Discourse, closed or otherwise. That's just the best tool for the job. And it's used by a lot of open source projects, so that made it really easy when I was writing the cap for that to kind of make those justifications for control of our own data, things like that. But generally speaking, we don't really have a strong criteria that says something has to be open source or stuff like that.

ADAM GLICK: What about for the automation that you're building? Is all the automation also built in Go, for instance, or if someone is automating one of these other processes, they could write in another language they're more familiar with?

JORGE CASTRO: They actually sit in GitHub. I know most of it is Go. I don't know enough about the specific tools because that's a different part of SIG Contributor Experience. But the tech leads work with SIG testing there. But all of the tools and stuff that we write is all open source. Like, if you're running a Slack and you wanted to run Catherine's moderation tools, you can just snag them from the Kubernetes orgs.

So we do make our infrastructure obviously open. I don't think we have a hard dependency. If Zoom were to turn evil or something tomorrow, I think it would be tough, but we would figure something out. You know what I mean? There are some considerations because we do have contributors in China, and that makes things very complicated as far as the tools that we can use.

But at the same time, sometimes it doesn't matter what video platform we use. If we switch to the other one, there's a good chance that it would be not accessible in China. So that's one of those cases where it's like, OK, also make sure that you're posting a thing onto Discuss because we know they can get that in China. We know that they can get GitHub in China. So that's a challenge.

CRAIG BOX: You were one of the returning officers for the Kubernetes Steering Committee election last week. Can you tell us a little bit about that election and the process behind it?

JORGE CASTRO: I've been fortunate to be involved in every Kubernetes election. So this is the first one, actually, where the bootstrap committee is moving to emeritus status, which is retirement, basically.

CRAIG BOX: For people who aren't familiar, what was the bootstrap committee?

JORGE CASTRO: OK, I can just tell you the whole history. What happened was Kubernetes needed governance. So they were writing out-- it's not really the Constitution, but all the things in the community repo that ended up being, like, the charters and things like that. And they were like, well, we need to have a body that's elected by the contributors that kind of steers the project.

And at first, they didn't really know what to do. So they kind of just said, you know what? These are the people that have been around-- co-founders. They've been around for a while, whatever. Let's just pick these people as the bootstrap committee. So that's Joe Beda, Tim Hockin, Brandon Philips, Brendan Burns. I can't remember them all, but people who've been around a while and kind of knew the project.

Then a year after, we had the first election, which they added I want to say three or four people to the steering committee. And at some point, the steering committee ballooned up in size to 13 people. So they were onboarding the new elected people while they were doing steering business. And then in this election, all the initial bootstrap people expire, and the people that we're bringing on are elected. So now with last year's members, the steering committee is now 100% elected by the contributors. And then bootstrap, they're going to go on and do other things, I suppose.

CRAIG BOX: What are the responsibilities or powers of members of the Kubernetes Steering Committee?

JORGE CASTRO: Well, this is something that people are confused about all the time, so I'm happy to talk about it. Steering's charter is basically to not run the project. The project is effectively run by the SIGs, right? They own the code. They have direction to it. Steering kind of just sits there when something affects multiple things that needs to either be resolved or an allocation issue. Or hey, steering, there's this part of the project that is underserved.

Steering, I like to say, they're kind of always looking to delegate a responsibility to someone to do that kind of stuff. They do have a public meeting. You can sit in on it. You can listen to what they talk about. They have a publicly available backlog. And you can just sit there and watch the meeting as it occurs in the business that they talk to. It's a lot of boring things. But it's stuff that has to get done, right?

CRAIG BOX: If the SIGs are ultimately responsible for the code, why isn't the power vested in them? Why isn't there a Council of the SIGs, for example?

JORGE CASTRO: Well, the power is invested in them for a lot of it, right? Usually, it's like, the steering wouldn't say, we want the cluster installation experience to look like this, right? That's delegated down to SIG Cluster Lifecycle. So in every SIG, every SIG has a charter file in their little SIG directory. It's called charter,md, and it tells exactly what they're responsible for and what they're not responsible for.

And then during the process this past year, all of these SIGs have worked with steering to get these charters approved and then merged into the project. That's actually something I should have mentioned before. If I were to say the biggest change that we've had in the past year is SIGs now have explicit charters, and steering has explicit charters. And everything is kind of divided up exactly how the work is being done currently right now.

ADAM GLICK: You mentioned the election process is now an open election from contributors within the community. Does it align with how much people contribute to the project, or is it just who the community votes for? And what do you think about the concept of electioneering and people essentially running for office?

JORGE CASTRO: In order to vote, steering committee, they pick out a criteria. And at some point, we have to use a number. So we say 50 contributions in the past year was the criteria for this one. So we went, dug through dev stats. We come up with a list. And then we actually have an exemption form, because it's important to us. There's a lot of work that happens outside of GitHub, right? There are people whose work does not show up in GitHub.

And Kubernetes has always been very cognizant of people who are doing work that isn't developer work because you need those people to do stuff, right? A healthy project has people who are doing non-engineering work to help the project out do a bunch of things. So we have a form there you can say, I didn't show up in GitHub or whatever, but these are the things I've been doing in core Kubernetes. And then we look at that, and then we say, OK, that's enough. You should vote.

As far as nominations and electioneering and stuff, it's actually explicit in the guidelines for the elections and things like that. So the nomination is basically you post to the mailing list, and then you need two people from a company or affiliation that isn't yours, so either two independents or different companies or whatever. And then that's it. You do a pull request with your little biography on why you want to run. And there's no electioneering. People don't post their platforms or anything like that on a mailing list. There's no debates. We don't really--

ADAM GLICK: There's no campaigns. People aren't buying ads to put on the site.

JORGE CASTRO: Yeah, it's pretty explicit. It's not going to be like, welcome to the community meaning. Vote for Pedro. It's not like that. But they do check in a little bio into the thing that the-- and then we put together a little voters' guide that says, here are the rules. Here are the nominees. This is the schedule. If you don't get your ballot, these are the people to contact, things like that.

And then we use a service called CIVS to do a Condorcet election, which is familiar to those of you who came from OpenStack. Debian has been using a similar service for a long time. So when Paris and I were initially looking at how do we-- steering wants us to figure out how to run an election. Let's do some investigation. So we looked at a bunch of projects. And Debian has been doing these sorts of elections for going on over 20 years now. So it's like, well, that's a good place to start.

CRAIG BOX: The four selected members for the steering committee were Christoph and Derek from Red Hat, Nikhita from Loodse, and Paris from Google, who we've mentioned multiple times throughout this podcast. Many, if not all of them, have been nominated or won the Chop Wood, Carry Water Award in the past. It feels like the selection of the community this time around was not necessarily the people who were the biggest technical contributors or had been with the project for the longest, but it was the people who are pulling their weight in a community fashion. How do you feel about that being the criteria that people seem to have used for the choice this time around?

JORGE CASTRO: If you look at the list of candidates, there are no bad candidates on that list. Like, the project is very fortunate to have people who are, A, willing to volunteer. This is not an easy job. There are times I sit on these steering meetings, and you could see on their face. It's like, ugh, there's some tough work that has to happen. So just the fact that we had that many people willing to say, you know what? I'm willing to go the extra mile for this, because you can't do steering kind of like in an hour in a week. It's not one of those roles that's like a beginner role or something. You have to manage that.

ADAM GLICK: It's a serious commitment of time.

JORGE CASTRO: Yeah, you have to have quorum when you meet. When you go to KubeCon, there's things that you have to do. So just the fact that we have that many people just willing to volunteer, I think it's awesome. And I think it shows the health of the community, right? If it was like, hey, people, we need someone to step up here to do this work, that would be really kind of a bummer thing, which does happen to some open source projects, right, at some point. But we're fortunate where we have people to volunteer their time. I think it's great.

CRAIG BOX: The community, of course, isn't all just grunt work and slaving away on these things. There's a lot of fun that happens as well. I hear you're part of a Kubernetes clan, playing online games. I also am a gamer, so close to my heart.


CRAIG BOX: What can you tell me about the Kubernetes clan?

JORGE CASTRO: This is just some really great-- some of the people you mentioned. This is a day job for me, right? I get paid to do this. And this is an open source thing. It's not just Kubernetes. Like, you really do make friends doing this kind of stuff, going to these conferences, hanging out. I hate to say it. I don't really go to KubeCon and Cloud Native Con for the talks. I mean, yeah, I have to go and they're useful for me, but I go to see-- hang out with my friends that I work with every day, who might not be co-workers at my actual company.

So after work, we'll game. We're doing "Destiny 2" right now. We've played "Overwatch" and we just kind of hang out. You say we're there for fun, and then you start talking about work about halfway through a raid. It's not-- the work-life balance there might be a trick, but.

ADAM GLICK: Should we start including people's gamer tags and the Steam aliases, along with their Twitter alias?

JORGE CASTRO: Yeah, but gaming is weird, too. I was like, oh, we need to start an official Kubernetes clan or whatever. And then you start to think about all the work that it takes to create a Kubernetes something, right? And I was like, aw, we'd have to bring in the code of conduct and then trademark. You know what? Let's just all game on the side and hang out. I don't feel like having to write a charter for the Kubernetes Destiny Clan-- steering approve it.

CRAIG BOX: But if you decided to, I know it would be in good hands.

JORGE CASTRO: But it's just a fun thing to do. And that's just something we do. I know a lot of people just get together. I know they're planning on doing a Disneyland trip with Justin Garrison when they go to KubeCon. I know people stay after to hang out with their friends after KubeCon, Cloud Native Con. Or they come early to go to the Rejekts conference, right?

CRAIG BOX: With a K.

JORGE CASTRO: Yeah, you have a conference of what are typically declined talks, and it has multiple thousands of people going, right? And people love to go to this kind of stuff. So when people self organize outside of the core Kubernetes community, I think it really kind of shows how dedicated people are and just how passionate they are about this.

CRAIG BOX: And that feels like a great time to say Jorge, thank you so much for joining us today.

JORGE CASTRO: Thanks for having me. This was a lot of fun. And if any of you out there are interested in contributing, seriously just come find us in SIG Contributor Experience and find me. Literally, this week, there was a person that showed up that just wanted to translate the Kubernetes contributor cheat sheet to Indonesian, right? And then we got to fix it in an hour or whatever.

So anything that you want to do, we're not perfect, but we will try our best to ensure that there's a place for you here that you're finding you're having a good time, and it's fun, and it's rewarding for you. We absolutely love it. Not just me, ping myself, Paris, Josh Berkus, Jonas, Don Foster, Christoph Blecker, Nikhita. Aw, I told myself I wouldn't list names because I'll forget someone, so if I forgot someone-- Bob Killen, Jeff, Stephen Augustus, sorry.

CRAIG BOX: You can find an authoritative list of Jorge's names and friends in our show notes.


CRAIG BOX: And you can find Jorge on Twitter at @castrojo.


Thanks for listening. As always, if you've enjoyed the show, please help us spread the word and tell a friend. If we have any feedback for us or want to get your project on next week's show, you can find us on Twitter at @kubernetespod, or reach us by email at kubernetespodcast@google.com.

ADAM GLICK: You can also check out our website at kubernetespodcast.com, where you'll find transcripts and show notes. Until next time, take care.

CRAIG BOX: Catch you next week.