First a little backstory, for the non-technical people in my reading audience. I’ll try to keep it brief.
You may have heard of
virtual machines? They are software that mimics a laptop or server. So for example, you can have a Windows laptop, but run a Linux virtual machine on top of it if you want to. And the VM behaves exactly like a Linux laptop would. Well, the next software evolution from VMs is a
container. When you create a VM, the virtual machine contains all sorts of things that you might not need. The same way a new laptop has all sorts of programs you might never use (in my case it’s browsers that I don’t use, and all those games). When you create a container, you only install the
exact software that you need, and nothing more. So they’re much leaner/smaller, and you can run more containers than you can VMs on the same hardware. The most popular software to manage containers is called
Kubernetes, and the most popular way to install containers on a Kubernets platform is using
Helm Charts. OK, that’s the background.
At my current job we support Helm Charts for customers to install our software. BUT, we don’t use Helm Charts when we install our own software internally, we use something else. As a result, since we don’t use Helm Charts, the engineering team doesn’t really know diddly squat about them. And even our most experienced Engineer is intimidated by Helm, and complains that he doesn’t understand it. BUT our customers use Helm Charts, and they have to install our product using Helm charts. I’m sure you can see where this is going, can’t you?
When we have a release and update the Helm charts, we often do it badly so that there are bugs, or even worse the software can’t install. So our open source customers then have to log bugs. And they submit fixes because sometimes the problem is obvious. Or they write new features, because they need to be able to configure something we hadn't thought of. But the Engineering team pretty much ignores the issues, and somehow never get around to reviewing their code submissions until either I beg them to or someone from the community finds someone’s name or email address and pesters them personally. People tweet at us. One guy tracked people down on LinkedIn and sent them messages that way. It’s a mess. And it’s embarrassing and makes us look bad.
My Developer Advocate buddy Jay had an idea a while back to form a group of volunteers from the Community to tackle the problem. And then the idea went nowhere for a couple of months. When we met up at the offsite in Madrid, we decided to resurrect the idea and see if we could get the team to let us try it for a three month pilot program for a Helm Maintainers Group. This time we got the approval. Whee! We have two developer advocates, myself, and three Community Champions, people who we’ve already recognized for helping out in the Community, answering questions on the Community forum and Community Slack and submitting bug fixes. I don’t know much about Helm (yet). But it’s a skill I’d like to add to my toolbox, so I have a couple of books and I’ve signed up for a couple of online courses. For the time being, I’m around because I have permission to push buttons on the repo that only employees can push.
We had our kick off meeting last week (Tuesday the 24th) and then I spent the rest of the week going through and getting all the Helm Charts pull requests into a Google Spreadsheet so that we could triage them. Starting out we had something like 135 - 140 Pull Requests waiting to be reviewed. Between Jay and I, we’ve already closed about 45 as either too stale or no longer needed (because the fix was already in the code). One of our Community champions has started working his way through the spreadsheet, and I’ve already merged one PR for him. I saw him commenting on a lot of other PRs, asking for changes or asking people to update to the latest version of the code. So he’ll probably get through all the extra small ones this week.
I’m so excited that we’ve gotten so much done in only a week. Yeah, we do still have about 90 PRs to deal with. I’m hoping that we can get through all of the biggest ones in the next month or two, and then maybe we can work on some of the backlog of issues and bug reports.