Merge pull request #1909 from bgrant0607/subprojects

Add subprojects

2 files changed, 40 insertions, 26 deletions

diff --git a/README.md b/README.md
index 16a597e2..7fb1091b 100644
--- a/README.md
+++ b/README.md
@@ -15,7 +15,7 @@ For more specific topics, try a SIG.
 
 ## SIGs
 
-Kubernetes is a set of projects, each shepherded by a special interest group (SIG).
+Kubernetes is a set of subprojects, each shepherded by a Special Interest Group (SIG).
 
 A first step to contributing is to pick from the [list of kubernetes SIGs](sig-list.md).
 
diff --git a/governance.md b/governance.md
index 083211fd..30dd9203 100644
--- a/governance.md
+++ b/governance.md
@@ -25,10 +25,11 @@ See [community membership]
 
 # Community groups
 
-The project has 3 main types of groups:
+The project has 4 main types of groups:
 1. Special Interest Groups, SIGs
-2. Working Groups, WGs
-3. Committees
+2. Subprojects
+3. Working Groups, WGs
+4. Committees
 
 Note that the project is also in the process of forming a Steering
 Committee, details of which will be documented soon.
@@ -60,18 +61,16 @@ responsible for the operation of the SIG and for communication and
 coordination with the other SIGs, the Steering Committee, and the
 broader community.
 
-We still have work to do to unify people organization via SIGs and
-code organization using [OWNERS](contributors/devel/owners.md), and to
-find homes for all subparts of the project, such as the build
-system. We also need to create a charter for each SIG to more clearly
-specify its scope (topics, subsystems, code repos and directories),
-responsibilities, areas of authority, how members and roles of
-authority/leadership are selected/granted, how decisions are made, and
-how conflicts are resolved. A template for intra-SIG governance should
-be developed in order to simplify SIG creation, but SIGs should be
-relatively free to customize or change how they operate, within some
-broad guidelines and constraints imposed by cross-SIG processes (e.g.,
-the release process) and assets (e.g., the kubernetes repo).
+Each SIG must have a charter that specifies its scope (topics,
+subsystems, code repos and directories), responsibilities, areas of
+authority, how members and roles of authority/leadership are
+selected/granted, how decisions are made, and how conflicts are
+resolved. A [short template] for intra-SIG governance has been
+developed in order to simplify SIG creation, and additional templates
+are being developed, but SIGs should be relatively free to customize
+or change how they operate, within some broad guidelines and
+constraints imposed by cross-SIG processes (e.g., the release process)
+and assets (e.g., the kubernetes repo).
 
 A primary reason that SIGs exist is as forums for collaboration.
 Much work in a SIG should stay local within that SIG. However, SIGs
@@ -83,14 +82,32 @@ community.
 See [sig governance] for more details about current SIG operating
 mechanics, such as mailing lists, meeting times, etc.
 
+## Subprojects
+
+Specific work efforts within SIGs are divided into **subprojects**.
+Every part of the Kubernetes code and documentation must be owned by
+some subproject. Some SIGs may have a single subproject, but 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.
+
+Example subprojects for a few SIGs:
+* SIG Network: pod networking (CNI, etc.), Service (incl. kube-proxy),
+Ingress, DNS, and Network policy
+* SIG Apps: workload APIs, Helm, Kompose, ...
+* SIG Cluster Lifecycle: kubeadm, kops, kubespray, minikube, ...
+
+Subprojects for each SIG are documented in [sigs.yaml](sigs.yaml).
+
 ## Working Groups
 
 We need community rallying points to facilitate discussions/work
-regarding topics that are too young/short-lived, or narrow/small, or
-decoupled from specific efforts to be tied to ownership as SIGs or
-Committees are, this is the purpose of Working Groups (WG). The intent
-is to make Working Groups relatively easy to create and to deprecate,
-once inactive.
+regarding topics that are short-lived or that span multiple SIGs.
+This is the purpose of Working Groups (WG). The intent is to make
+Working Groups relatively easy to create and to deprecate, once
+inactive.
 
 ## Committees
 
@@ -139,16 +156,13 @@ should follow the procedures outlined in the [incubator document](incubator.md).
 use the [Apache Licence version 2.0](LICENSE). Documentation repositories should use the
 [Creative Commons License version 4.0](https://git.k8s.io/website/LICENSE).
 
-# Incubator process
-
-See [incubator process]
-
 # CLA
 
 All contributors must sign the CNCF CLA, as described [here](CLA.md).
 
 [community membership]: /community-membership.md
 [sig governance]: /sig-governance.md
-[incubator process]: /incubator.md
+[owners]: community-membership.md#subproject-owner
+[short template]: committee-steering/governance/sig-governance-template-short.md
 
 [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]()