CNCF community,

The Kubernetes project is at full tilt.

Please see below a summary of the recent Leadership Summit, a
gathering of mostly technical folk driving this project. Apologies if
some hyperlinks are missing - please refer to Brian's post @
https://groups.google.com/forum/#!topic/kubernetes-dev/PpgLgkffr3o

At the CNCF we want many such projects - all learning from each other.
Help make that happen: As you can see the project is breaking the
bounds of even modern tools and structures. There are many
opportunities to help - please speak up here, or contact the relevant
project leads.

alexis



---------- Forwarded message ----------
From: 'Brian Grant' via Kubernetes developer/contributor discussion
<kubernetes-dev@...>
Date: Mon, Jun 12, 2017 at 8:18 PM
Subject: Leadership summit summary and outcomes
To: "kubernetes-dev@..." <kubernetes-dev@...>


A group of O(100) of us met on Friday, June 2, at Samsung in San Jose.
We're working on getting notes from the meeting checked into github.
In the meantime, I thought I'd give a summary. Others who attended are
welcome to follow up with their takeaways.

Tim (@thockin) presented an overview of the state of the project.
After covering the great progress we've made, we talked about having
reached an inflection point in the project. There was broad consensus
among those present that the project needs to increase focus on:

Finishing features/APIs, especially table-stakes ones, such as
Deployment, Ingress, RBAC, encrypted Secrets (as opposed to adding net
new concepts)
Architectural layering, modularity, project boundaries
Stability, predictability, fixing bugs, paying down technical debt
Easier "on ramps": user docs, examples, best practices, installers,
tools, status, debugging
Contributor experience, tooling, and testing
Governance
Conformance

We discussed the need to refresh the roadmap assembled in November,
which was presented by Aparna and Ihor, along with some interesting
data, such as penetration of container orchestrators (~7%) and which
SIGs have the most open issues (Node and API machinery).

Brandon (@philips) and I presented more of the motivation for the
Governance proposal, and solicited nominations for the Steering
Committee. Please, please, please do comment on the governance
proposal, even if just to LGTM, and seriously consider running for the
Steering Committee. We asked SIGs to start working on their charters.
I also spoke about the role of CNCF with respect to the project.

I presented my architecture roadmap proposal, and received positive
feedback. It put the extension mechanisms underway, such as API
aggregation, into context. One outcome was the mandate to form SIG
Architecture. An Extensibility Working Group was also discussed, but
perhaps the Architecture SIG could serve the role of driving the
needed extension mechanisms forward.

The discussion about code organization mostly centered around the
effort to scale the project to multiple github repos and orgs. Github
provides exactly 2 levels of hierarchy we need to use both
effectively. By multiple metrics kubernetes/kubernetes is the most
active repo on Github. All of Github's mechanisms (e.g., permissions,
notifications, hooks) are designed to support small, focused repos.
Every other project of comparable scale is comprised of many repos
(e.g., Nodejs has ~100 and CloudFoundry has ~300). The
kubernetes/kubernetes commit rate peaked in July 2015, when the
project was 10x smaller, and most commits on the project are already
outside kubernetes/kubernetes.

Additionally, there is a desire to at least start new functionality
outside the main repo/release. Since Kubernetes is an API-centric
system and since we're using the API machinery for component
configuration as well, the API machinery needs to be made available to
other repos in order for any significant development to be feasible
outside kubernetes/kubernetes. We're using Service Catalog
(https://github.com/kubernetes-incubator/service-catalog) as a driving
use case for this. We've also started serious work on moving out
kubectl, which is at least as important symbolically as it is
technically, and have stopped accepting new cloudprovider
implementations.

The discussion about areas falling through the cracks focused on what
to do about them. There was consensus that some SIG needs to own the
build machinery. Proposals included SIG release, SIG testing, SIG
contributor experience, and SIG build (i.e., a new SIG). It was
suggested that whatever SIG owns the build should also own utility
libraries. In addition to strategies that have been discussed before
(e.g., accountability metrics, leaderboard, help wanted / janitors,
rotations), we discussed the idea of creating job descriptions for
more project/SIG roles, as has been done for the release team, as a
way to make it more clear to participating companies and individuals
what areas need to be staffed.

I'm looking forward to the notes from the SIG breakout, which was at
the same time as the "falling through the cracks" session. It sounds
like there were good discussions about SIG leadership, organization,
communication, consolidation, participation, and other topics.

Similar for the community effectiveness breakout, which discussed a
number of topics, including how to convert passive attendees to active
participants.

Look for the full summit notes over the next couple weeks, as well as
follow up on action items during the community hangout.

Thanks to Cameron for organizing the event, to everyone else who
helped with the summit, to Samsung for hosting it, and to everyone who
participated.

--Brian

--
You received this message because you are subscribed to the Google
Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to kubernetes-dev+unsubscribe@....
To post to this group, send email to kubernetes-dev@....
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs4MYHjS%3DhJTDSHCQWCtUcubOun9MKnreY5rcqerwy_GkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.