Define community groups, as they currently exist, taking some text

from the draft Recommended Project Structure document.

1 files changed, 108 insertions, 3 deletions

diff --git a/governance.md b/governance.md
index ea44fb27..d0ff2855 100644
--- a/governance.md
+++ b/governance.md
@@ -23,9 +23,114 @@ environment for our contributors and users. We want everyone in the community to
 
 See [community membership]
 
-# SIG Governance
-
-See [sig governance]
+# Community groups
+
+The project has 3 main types of groups:
+1. Special Interest Groups, SIGs
+2. Working Groups, WGs
+3. Committees
+
+Note that the project is also in the process of forming a Steering
+Committee, details of which will be documented soon.
+
+## SIGs
+
+The Kubernetes project is organized primarily into Special Interest
+Groups, or SIGs. Each SIG is comprised of members from multiple
+companies and organizations, with a common purpose of advancing the
+project with respect to a specific topic, such as Networking or
+Documentation. Our goal is to enable a distributed decision structure
+and code ownership, as well as providing focused forums for getting
+work done, making decisions, and onboarding new contributors. Every
+identifiable subpart of the project (e.g., github org, repository,
+subdirectory, API, test, issue, PR) is intended to be owned by some
+SIG. 
+
+Areas covered by SIGs may be vertically focused on particular
+components or functions, cross-cutting/horizontal, spanning many/all
+functional areas of the project, or in support of the project
+itself. Examples:
+* Vertical: Network, Storage, Node, Scheduling, Big Data
+* Horizontal: Scalability, Architecture
+* Project: Testing, Release, Docs, PM, Contributor Experience
+
+SIGs must have at least one and ideally two SIG leads at any given
+time. SIG leads are intended to be organizers and facilitators,
+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 unifiy 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).
+
+A primary reason that SIGs exist is as forums for collaboration. 
+Much work in a SIG should stay local within that SIG. However, SIGs
+must communicate in the open, ensure other SIGs and community members
+can find notes of meetings, discussions, designs, and decisions, and
+periodically communicate a high-level summary of the SIG's work to the
+community.
+
+See [sig governance] for more details about current SIG operating
+mechanics, such as mailing lists, meeting times, etc.
+
+## 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.
+
+## Committees
+
+Some topics, such as Security or Code of Conduct, require
+discretion. Whereas SIGs are voluntary groups which operate in the
+open and anyone can join, Committees do not have open membership and do
+not always operate in the open.  The steering committee can form
+committees as needed, for bounded or unbounded duration.  Membership
+of a committee is decided by the steering committee.  Like a SIG, a
+committee has a charter and a lead, and will report to the steering
+committee periodically, and to the community as makes sense, given the
+charter.
+
+## Cross-project Communication and Coordination
+
+While most work shouldn’t require expensive coordination with other
+SIGs, there will be efforts (features, refactoring, etc.) that cross
+SIG boundaries.  In this case, it is expected that the SIGs coordinate
+with each other and come to mutually agreed solutions. In some cases,
+it may make sense to form a Working Group for joint work.  Cross-SIG
+coordination will naturally require more time and implies a certain
+amount of overhead.  This is intentional to encourage changes to be
+well encapsulated whenever possible.
+
+On the other hand, several SIGs do have project-wide impact, for
+example Release, Testing, and API Machinery. Even those that do not
+may sometimes need to make changes or impose new processes or
+conventions that affect other SIGs. In these cases, project-wide
+communication processes will need to be followed. For example,
+proposals with project-wide impact will need to be announced more
+broadly, with the opportunity for members of other SIGs to provide
+feedback and guidance. However, the SIG that owns the area, according
+to its charter, will own the decision. In the case of extended debate
+or deadlock, decisions may be escalated to the Steering Committee,
+which is expected to be uncommon.
+
+The exact processes and guidelines for such cross-project
+communication have yet to be formalized, but when in doubt, use
+kubernetes-dev@googlegroups.com and make an announcement at the
+community meeting.
 
 # Repository guidelines