How I became a Kubernetes maintainer in 4 hours a week

"I want to contribute to Kubernetes, but I don't know where to start."

I have heard (and even said) versions of this sentiment many times since Kubernetes started gaining influence. So, over the last year, I've spent time contributing to the project, and I've found it worth every minute.

I've discovered that Kubernetes is a project with the right scale for anyone to make an impact in whatever time they have available in their schedule. For me, that was just four hours a week. No more, no less.

After six months at four hours a week, I found myself the leader of a subgroup that's making a significant difference around non-code contributions to the project.

I'll share some of what I've learned about contributing to Kubernetes. I hope it helps you find the focus and time to join in.

Where to start

The Kubernetes community personifies the principle of showing up. I "lurked" on the community channels for a while but did not spend much time talking in them. As soon as I started to join in and (eventually) speak up, I experienced an immediate change in my sense of community.

Join in where, you ask? Here are the key channels to keep an eye on:  

• The Kubernetes developer mailing list (k/dev for short) is the official channel for news from all Kubernetes contributors.
• The Kubernetes Slack channel, where over 100,000 registered members discuss the project in hundreds of channels.
• Weekly special interest group (SIG) meetings where work gets done collaboratively via videoconference.
• The Kubernetes Community GitHub repository, which is the central repository for community activity in the project.

The channels combine synchronous communication (real-time, quick feedback) with asynchronous (eventual, thoughtful feedback). More than any other project I have contributed to, Kubernetes has a subtle bias toward synchronous communication. Being in a meeting or part of a Slack discussion is a valued way to be part of the action. The more you are active in real time, the more influence you can have in the long run. Or so it seems.

Despite the value of sync, don't discount the asynchronous work done in Kubernetes land. All significant activity, and a backlog of thoughtful ideas that need someone to work on, are tracked through GitHub issues. The mailing list is also increasingly active and a great place to show up to connect.

Regardless of the channel, the conclusion is the same: You have to show up.

How I commit the time

Many people work on Kubernetes full time. I am not one of them, and if you are reading this article, I assume you aren't one of them, either. So, when you have a 40-hour-a-week job, how do you carve out four precious hours in your day to contribute to an open source project?

In my case, it began by understanding what my business values. I have the good fortune to work for an organization that defines itself through open source contributions. That's a good start. My organization also values open source experience in general and, more specifically, Kubernetes knowledge. So, as someone whose value to the organization can be measured in understanding Kubernetes, it's fair to assume I need to spend time with the project.

With the business proposition clear to me, my next step was to start. I didn't begin with an email request or a proposal to do this as part of my job. It's my job to manage my skill development, and I decided to maximize that through (time-limited) open source contributions. At the equivalent of a half-day of work per week, I'm trusted to budget my time. The caveat is I have to stop contributing if it (a) begins to impede my day job or (b) does not result in any meaningful value to my day job.

After about a month of contributing, I shared some of my new Kubernetes knowledge (which I acquired by showing up regularly) with my team, my manager, and my manager's manager. They were all excited about what I was sharing. So, I proposed the idea of continuing, and they overwhelmingly agreed it was a good idea.

Eight months later, I'm still contributing, and it's still adding value.

What do four hours of contribution look like?

Here is my checklist for a sustainable contribution strategy in the Kubernetes community:

• Join your SIG meeting once a week (1 hour)
• Skim the k-dev mailing list twice a week for 15 minutes (30 min.)
• Socialize on Slack or Twitter once a week (30 min.)
• Most weeks, block two more one-hour slots to complete your action items (1 to 2 hours).
• Once a month, take one of those hours and join the monthly community call (0-1 hour).

My first three months were all about getting oriented, and they paid off. At the start, plan to spend a good bit of time soaking up the context. If no SIG immediately grabs your attention, start with Contributor Experience. This group exists to help guide and support all contributors.

Sticking to this time commitment, in six months, I went from sitting in on the Contributor Experience SIG to leading its Upstream Marketing subgroup. In my case, the timing was right, and the role was appropriate to my skills, but it goes to show that sustained contribution can quickly pay off.

Contributing across time zones

The synchronous activities—meetings and Slack messages—do have a bias toward the US Pacific Time Zone. There is no sugar-coating that part. Every Friday at our subgroup call, a handful of regulars sign in after 8pm or 10pm in Europe and Asia. It's not ideal timing for some.

But while these synchronous calls are helpful for getting to know the group, contributors can quickly switch to asynchronous options and still significantly impact the project. GitHub, email, and even async Slack are 90% of where work gets done. For some SIGs, it's closer to 100%. Be upfront with other SIG members, and I am confident they will help you get meaningful work done asynchronously.

Bring your unique contribution

Here's my big takeaway from this: Large projects thrive through sustained contribution. Making small contributions over an extended period is more valuable than a big fly-by-night pull request.

I go through these painstaking details of how I manage my time to highlight an opportunity I believe many of us may not realize we have. Often, we have more say than we think about how we spend some of our work weeks. And I hope you can carve off some of it for open source. You will offer a unique experience that can make a difference.