search

kubernetes / steering

The Kubernetes Steering Committee
Apache License 2.0
84 stars 61 forks source link

Formalize the concept of subprojects #200

Open spiffxp opened 6 years ago

spiffxp commented 6 years ago

This is based on / inspired by a SIG Architecture proposal to expand SIG metadata and flesh out OWNERS

This is driven by a steering committee goal of ensuring that our organizational structure maps to our code structure.

Every part of the Kubernetes code and documentation should be owned by a Special Interest Group (SIG). However, many SIGs have multiple significant subprojects with distinct (though sometimes overlapping) sets of contributors and owners, who act as subproject’s technical leaders: responsible for vision and direction and overall design, choose/approve change proposal (KEP) approvers, field technical escalations, etc. We should formally recognize that.

For example, SIG Network potentially could be divided into multiple subprojects: pod networking (CNI, etc.), Service, Ingress, DNS, and Network policy. SIG Apps has the workload APIs, Helm, and Kompose. SIG Cluster Lifecycle has kubeadm, kops, kubespray, minikube, etc. SIG API machinery has apiserver, client libraries, API discovery and OpenAPI, CRD, API aggregation, and admission extension. In addition to Kubelet proper, SIG Node has multiple CRI implementations underway. Maybe some of these subprojects should be grouped, but hopefully you get the idea.

I'd like to start by implementing this concept in sigs.yaml. This ensures the information is machine-readable, generated README's contain human-readable information, and we start with a single source of truth.

Strawman:

Looking at SIG Apps as an example:

Looking at SIG Contributor Experience as an example:

I am putting together an implementation based on this strawman with a total guess of single-repo subprojects based on first-pass by @bgrant0607, so we have a concrete example to iterate on. The intent isn't to voluntold SIG's into owning repos, but to identify where our gaps lie.

/sig contributor-experience /sig apps Since I mention you two as examples

/committee steering /priority important-soon /assign

spiffxp commented 6 years ago

/sig architecture

bgrant0607 commented 6 years ago

One idea that just occur to me is that maybe the area/ labels should be replaced by subproject/ labels.

fejta-bot commented 6 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

cblecker commented 6 years ago

/remove-lifecycle stale

grodrigues3 commented 6 years ago

@spiffxp where are we with this? some sigs do have sub-projects . Do we need to push the idea more broadly? Do we have any metrics for how well this has been rolled out/accepted?

spiffxp commented 6 years ago

There is little to no automation that consumes sigs.yaml outside of the docs generator in this repo. As a thing that is commonly understood, I still think we have work to do on sigs/wgs/subprojects.

To tighten things down I've got two umbrella issues:

TBH right now I'm less concerned about the fact that we also haven't:

I would say if we get to the point where we've got good label hygiene based on these we can track metrics

nikhita commented 5 years ago

There is a PR open to add a project-manager-like role for subprojects here: https://github.com/kubernetes/community/pull/3413.

I think we can take a look at updating automation once we finalize on the subproject roles.

timothysc commented 5 years ago

poke, can we close this now?

spiffxp commented 5 years ago

Here's what's missing: a very tight machine readable definition of subproject owners. The sig-governance definition of the role is pretty crisp, except that it says they're defined in sigs.yaml.

Today in sigs.yaml, subprojects are defined by a list of OWNERS files, and those OWNERS files have "approvers". Are subproject owners the union of all of the approvers listed therein? The intersection of those approvers?

This is the problem I was raising with SIG Cloud Provider's impending merge of other cloud provider SIG subprojects. Ideally there would be one subproject per cloud, each composed of many repos... but then how do we denote the people who have final say for cloud foo, while also denoting the "tech leads" for each repo? Subprojects as a list of owners files lack the hierarchy needed to make this distinction.

Options to overcome this:

None of these individually solves the tension between a desire to centralize the info, but distribute the authority. They all require something to walk OWNERS files and reconcile against or into a central place, so I'm going to start there.

spiffxp commented 5 years ago

Analysis of common owners https://gist.github.com/spiffxp/629ab537c2e1d59072aa3154c91459c0

bgrant0607 commented 5 years ago

/remove-sig arch

k8s-ci-robot commented 5 years ago

@bgrant0607: Those labels are not set on the issue: sig/arch

In response to [this](https://github.com/kubernetes/community/issues/1673#issuecomment-490140973): >/remove-sig arch Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
bgrant0607 commented 5 years ago

/remove-sig apps

spiffxp commented 5 years ago

/remove-sig architecture

fejta-bot commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

spiffxp commented 3 years ago

/remove-lifecycle stale /lifecycle frozen

BenTheElder commented 2 days ago

I think to a certain extent we did this by adding subproject leads as a formal role since this was filed.

bgrant0607 commented 2 days ago

I consider this to be done.