top project concerns that need focus

[Brian Grant]

I was asked by a few people to share what I think is important and which needs more project-wide attention.

The answer is: factors hampering the growth of the project, in the areas of contributor experience, cluster admin experience, user experience, and developer experience. 

Project health and contributor experience

My top concern is the health of the development effort, which I characterize as "contributor experience". 

The project has grown tremendously over the past 2 years, but unfortunately hasn't scaled as well as we need it to. We're working on a public PR metrics dashboard, but here's a sample of the data:

There are many reasons for this. As a community, we need to focus on solving them. I started a list of items here:

https://github.com/kubernetes/community/wiki/Roadmap:-Contributor-Experience

Some of the issues, such as the OWNERS implementation have been discussed for a long time. We need to make progress. There's not a SIG yet, but if you're interested in helping, please reach out to me.

One thing everyone can help with is PR reviews. You don't need to work for Google or Redhat in order to do PR reviews. You just need to familiarize yourself with part of the codebase, Go, and our conventions (see docs/devel). We could use help with doc reviews in kubernetes.github.io. 

Simplified cluster lifecycle / cluster admin experience

"Cluster lifecycle" is the creation, management (scaling, updates), and turndown of Kubernetes clusters. I also think of this as "cluster admin experience". This is critical to adoption of Kubernetes, because it is necessarily the first experience most users have with the system, before they can deploy their first app.

This issue has been getting a lot of attention since Dockercon, but we were already working on it. For example, Minikube was released with 1.3.

We could certainly use help in order to accelerate these efforts. If you want to get involved, check out the new Cluster lifecycle SIG.

As with contributor experience, there are many issues that need to be addressed. A sketch of the space can be found here:

https://github.com/kubernetes/community/wiki/Roadmap:-Cluster-Deployment

In 1.4, we're working on disentangling infrastructure provisioning and cluster bootstrapping, eliminating complex configuration, and reducing the number of steps required.

User experience

We've done a lot of work to make it easier to manage workloads in production environments, but haven't spent as much effort reducing barriers for new users. This not only turns off some potential new users, but also increases the support burden, such as questions on slack and stackoverflow.

One of the most critical things we need to do is to make our documentation sufficiently useful and discoverable. Right now, it's very hard to find even basic documentation (e.g., where is it documented how to set the command line of a container?) on kubernetes.io. In Q2 we developed a detailed site reorganization plan, including identification of content gaps, mocks, and templates, but need help implementing the plan:

https://github.com/kubernetes/community/wiki/Roadmap:-Docs

Get involved with SIG Docs if you're able to help.

In addition to documentation, we also need to make it braindead-simple to launch the most popular off-the-shelf applications, with no need for users to even read documentation. Most of these applications are stateful applications, such as databases, caches, message queues, etc. To address this need, we're working on improved support for stateful applications, on actually getting the application to work in realistic configurations, and on making it possible to deploy them easily (e.g., using Helm). The most natural home for that effort is SIG Apps.

Beyond those efforts, we have many other ideas, such as migration tools (e.g., kompose), numerous improvements to kubectl (https://github.com/kubernetes/community/wiki/Roadmap:-kubectl), and UI improvements (SIG UI). If you're not sure about how best to help, reach out to us on slack.

Developer experience

In order to really scale the Kubernetes community, we need most of the development to shift from the core to the ecosystem. Unfortunately, building on top of Kubernetes is too hard today. Part of the problem is the quality of our API documentation. Part of it is lack of supported client libraries, as was highlighted by the breakage of "go get pkg/api" this week. Developers shouldn't have to reverse-engineer the Kubernetes API from kubectl code and types.go, and shouldn't have to vendor in the whole source tree or manually fix our Swagger output in order to generate a working client. There are other challenges as well, but those are our current focus.

If you'd like to help in this area, get involved with SIG API Machinery.

That all said, the project has come a long way. We have one of the top github projects, with 32k commits. I haven't found any single github repository with a higher sustained human-generated commit rate. We're approaching a thousand contributors. About half of contributions are from outside Google. Over 1000 projects are based on Kubernetes.

Thank you all for your contributions. I can't wait to see what we build together over the next 2 years.

--Brian