Various governance clarifications

README.md

@@ -13,16 +13,27 @@ issues, mailing lists, conferences, etc.
 
 For more specific topics, try a SIG.
 
-## SIGs
+## Governance
 
-Kubernetes is a set of subprojects, each shepherded by a Special Interest Group (SIG).
+Kubernetes has three types of groups that are officially supported:
 
-A first step to contributing is to pick from the [list of kubernetes SIGs](sig-list.md).
+* **Committees** are named sets of people that are chartered to take on sensitive topics.
+  This group is encouraged to be as open as possible while achieving its mission but, because of the nature of the topics discussed, private communications are allowed.
+  Examples of committees include the steering committee and things like security or code of conduct.
+* **Special Interest Groups (SIGs)** are persistent open groups that focus on a part of the project.
+  SIGs must have open and transparent proceedings.
+  Anyone is welcome to participate and contribute provided they follow the Kubernetes Code of Conduct.
+  The purpose of a SIG is to own and develop a set of **subprojects**.
+  * **Subprojects** Each SIG can have a set of subprojects.
+    These are smaller groups that can work independently.
+    Some subprojects will be part of the main Kubernetes deliverables while others will be more speculative and live in the `kubernetes-sigs` github org.
+* **Working Groups** are temporary groups that are formed to address issues that cross SIG boundaries.
+  Working groups do not own any code or other long term artifacts.
+  Working groups can report back and act through involved SIGs.
+
+See the [full governance doc](governance.md) for more details on these groups.
 
-A SIG can have its own policy for contribution,
-described in a `README` or `CONTRIBUTING` file in the SIG
-folder in this repo (e.g. [sig-cli/CONTRIBUTING](sig-cli/CONTRIBUTING.md)),
-and its own mailing list, slack channel, etc.
+A SIG can have its own policy for contribution, described in a `README` or `CONTRIBUTING` file in the SIG folder in this repo (e.g. [sig-cli/CONTRIBUTING.md](sig-cli/CONTRIBUTING.md)), and its own mailing list, slack channel, etc.
 
 If you want to edit details about a SIG (e.g. its weekly meeting time or its leads),
 please follow [these instructions](./generator) that detail how our docs are auto-generated.
@@ -34,7 +45,11 @@ lead to many relevant technical topics.
 
 ## Contribute
 
-The [Contributor Guide](contributors/guide/README.md) provides detailed instructions on how to get your ideas and bug fixes seen and accepted, including:
+A first step to contributing is to pick from the [list of kubernetes SIGs](sig-list.md).
+Start attending SIG meetings, join the slack channel and subscribe to the mailing list.
+SIGs will often have a set of "help wanted" issues that can help new contributors get involved.
+
+The [Contributor Guide](contributors/guide/README.md) provides detailed instruction on how to get your ideas and bug fixes seen and accepted, including:
 1. How to [file an issue]
 1. How to [find something to work on]
 1. How to [open a pull request]

committee-steering/governance/README.md

@@ -28,6 +28,25 @@ All Kubernetes SIGs must define a charter defining the scope and governance of t
 - For minor updates to that only impact issues or areas within the scope of the SIG the SIG Chairs should
   facilitate the change.
 
+## SIG Charter approval process
+
+When introducing a SIG charter or modification of a charter the following process should be used.
+As part of this we will define roles for the [OARP] process (Owners, Approvers, Reviewers, Participants)
+
+- Identify a small set of Owners from the SIG to drive the changes.
+  Most typically this will be the SIG chairs.
+- Work with the rest of the SIG in question (Reviewers) to craft the changes.
+  Make sure to keep the SIG in the loop as discussions progress with the Steering Committee (next step).
+  Including the SIG mailing list in communications with the steering committee would work for this.
+- Work with the steering committee (Approvers) to gain approval.
+  This can simply be submitting a PR and sending mail to [[email protected]].
+  If more substantial changes are desired it is advisable to socialize those before drafting a PR.
+    - The steering committee will be looking to ensure the scope of the SIG as represented in the charter is reasonable (and within the scope of Kubernetes) and that processes are fair.
+- For large changes alert the rest of the Kubernetes community (Participants) as the scope of the changes becomes clear.
+  Sending mail to [[email protected]] and/or announcing at the community meeting are a good ways to do this.
+
+If there are questions about this process please reach out to the steering committee at [[email protected]].
+
 ## How to use the templates
 
 SIGs should use [the template][Short Template] as a starting point. This document links to the recommended [SIG Governance][sig-governance] but SIGs may optionally record deviations from these defaults in their charter.
@@ -41,9 +60,12 @@ The primary goal of the charters is to define the scope of the SIG within Kubern
 
 See [frequently asked questions]
 
+[OARP]: https://stumblingabout.com/tag/oarp/
 [Recommendations and requirements]: sig-governance-requirements.md
 [sig-governance]: sig-governance.md
 [Short Template]: sig-charter-template.md
 [frequently asked questions]: FAQ.md
 [sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml
 [sig-architecture example]: ../../sig-architecture/charter.md
+[[email protected]]: mailto:[email protected]
+[[email protected]]: mailto:[email protected]

governance.md

@@ -26,10 +26,10 @@ See [community membership]
 # Community groups
 
 The project has 4 main types of groups:
-1. Special Interest Groups, SIGs
-2. Subprojects
-3. Working Groups, WGs
-4. Committees
+* Special Interest Groups, SIGs
+  * Subprojects
+* Working Groups, WGs
+* Committees
 
 ## SIGs
 
@@ -52,8 +52,8 @@ itself. Examples:
 * 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,
+SIGs must have at least one and ideally two SIG chairs at any given
+time. SIG chairs 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.
@@ -62,7 +62,8 @@ 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
+resolved. See the [SIG charter process] for details on how charters are managed.
+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
@@ -79,7 +80,7 @@ community.
 See [sig governance] for more details about current SIG operating
 mechanics, such as mailing lists, meeting times, etc.
 
-## Subprojects
+### Subprojects
 
 Specific work efforts within SIGs are divided into **subprojects**.
 Every part of the Kubernetes code and documentation must be owned by
@@ -106,15 +107,28 @@ This is the purpose of Working Groups (WG). The intent is to make
 Working Groups relatively easy to create and to deprecate, once
 inactive.
 
-To propose a new working group, first find a SIG to sponsor the group. 
+Working groups do not own any code or subprojects. Instead, they are a place for
+people to discuss topics that cross SIG boundaries.
+
+Working groups are primarily used to facilitate topics of discussion that are in
+scope for Kubernetes but that cross SIG lines. If a set of folks in the
+community want to get together and discuss a topic, they can do so without
+forming a Working Group. As a community we will be looking for other ways to
+highlight and encourage a larger ecosystem (with things like slack channels)
+without offering any official endorsement.
+
+To propose a new working group, first find a SIG to sponsor the group.
 Next, send a proposal to [email protected] and also include
-any potentially interested SIGs. Wait for public comment. If there's 
-enough interest, a new Working Group should be formed. 
+any potentially interested SIGs. Wait for public comment. If there's
+enough interest, a new Working Group should be formed.
 
-Create a new mailing list in the from of kubernetes-wg-group-name. Working 
+Create a new mailing list in the from of kubernetes-wg-group-name. Working
 groups typically have a Slack channel as well as regular meetings on zoom.
 It's encouraged to keep a clear record of all accomplishments that's publicly
-accessible.
+accessible.  Like SIGs, working group communications and meetings should be
+open and be recorded for later viewing.
+
+Working groups are documented in [sigs.yaml](sigs.yaml).
 
 ## Committees
 
@@ -124,7 +138,7 @@ 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 has a charter and a chair, and will report to the steering
 committee periodically, and to the community as makes sense, given the
 charter.
 
@@ -151,17 +165,15 @@ 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
-[email protected] and make an announcement at the
-community meeting.
+The [KEP process] is being developed as a way to facilitate definition, agreement and communication of efforts that cross SIG boundaries.
+SIGs are encouraged to use this process for larger efforts.
+This process is also available for smaller efforts within a SIG.
 
 # Repository guidelines
 
-All repositories under Kubernetes github orgs, such as kubernetes and kubernetes-incubator,
-should follow the procedures outlined in the [incubator document](incubator.md). All code projects
-use the [Apache License version 2.0](LICENSE). Documentation repositories should use the
-[Creative Commons License version 4.0](https://git.k8s.io/website/LICENSE).
+All new repositories under Kubernetes github orgs should follow the process outlined in the [kubernetes repository guidelines].
+
+Note that "Kubernetes incubator" process has been deprecated in favor of the new guidelines.
 
 # CLA
 
@@ -170,6 +182,8 @@ All contributors must sign the CNCF CLA, as described [here](CLA.md).
 [community membership]: /community-membership.md
 [sig governance]: /sig-governance.md
 [owners]: community-membership.md#subproject-owner
-[short template]: committee-steering/governance/sig-charter-template.md
+[sig charter process]: committee-steering/governance/README.md
+[short template]: committee-steering/governance/sig-governance-template-short.md
+[kubernetes repository guidelines]: kubernetes-repositories.md
 
 [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]()

sig-governance.md

@@ -2,14 +2,15 @@
 
 In order to standardize Special Interest Group efforts, create maximum transparency, and route contributors to the appropriate SIG, SIGs should follow the guidelines stated below:
 
+* Create a charter and have it approved according to the [SIG charter process]
 * Meet regularly, at least for 30 minutes every 3 weeks, except November and December
 * Keep up-to-date meeting notes, linked from the SIG's page in the community repo
 * Announce meeting agenda and minutes after each meeting, on their SIG mailing list
 * Record SIG meeting and make it publicly available
 * Ensure the SIG's mailing list and slack channel are archived
 * Report activity in the weekly community meeting at least once every 6 weeks
 * Participate in release planning meetings and retrospectives, and burndown meetings, as needed
-* Ensure related work happens in a project-owned github org and repository, with code and tests explicitly owned and supported by the SIG, including issue triage, PR reviews, test-failure response, bug fixes, etc. 
+* Ensure related work happens in a project-owned github org and repository, with code and tests explicitly owned and supported by the SIG, including issue triage, PR reviews, test-failure response, bug fixes, etc.
 * Use the above forums as the primary means of working, communicating, and collaborating, as opposed to private emails and meetings
 
 In addition, SIGs have the following responsibilities to SIG PM:
@@ -18,19 +19,21 @@ In addition, SIGs have the following responsibilities to SIG PM:
 * actively track / maintain SIG features within [k/features](https://github.com/kubernetes/features)
 * attend [SIG PM](/sig-pm/README.md) meetings, as needed / requested
 
+[SIG charter process]: /committee-steering/governance/README.md
+
 ## SIG Roles
 
-Defining SIG Roles is a function of the SIG Charter.  
+Defining SIG Roles is a function of the SIG Charter.
 Guidelines for drafting a SIG Charter can be found [here](/committee-steering/governance/README.md).
 
-
 ## SIG creation and maintenance procedure
 
 ### Prerequisites
 
-* Propose the new SIG publicly, including a brief mission statement, by emailing [email protected] and posting to discuss.kubernetes.io, then wait a couple of days for feedback.
-* Ask a repo maintainer to create a github label, if one doesn't already exist: sig/foo.
-* Request a new [kubernetes.slack.com](http://kubernetes.slack.com) channel (#sig-foo) from the #slack-admins channel.  New users can join at [slack.kubernetes.io](http://slack.kubernetes.io).
+* Work with the Steering Committee to scope the SIG and get provisional approval.
+  Follow the [SIG charter process] to propose and obtain approval for a charter.
+* Ask a repo maintainer to create a github label, if one doesn't already exist: sig/foo
+* Request a new [kubernetes.slack.com](http://kubernetes.slack.com) channel (#sig-foo) from [@parispittman](https://github.com/parispittman) or [@castrojo](https://github.com/castrojo).  New users can join at [slack.kubernetes.io](http://slack.kubernetes.io).
 * Organize video meetings as needed. No need to wait for the [Weekly Community Video Conference](community/README.md) to discuss. Please report summary of SIG activities there.
  * Request a Zoom account by emailing Paris Pittman(`[email protected]`) and Jorge Castro(`[email protected]`). You must set up a google group (see below) for the SIG leads so that all the SIG leads have the ability to reset the password if necessary.
  * Read [how to use YouTube](/communication/K8sYoutubeCollaboration.md) for publishing your videos to the Kubernetes channel.
@@ -41,13 +44,13 @@ Guidelines for drafting a SIG Charter can be found [here](/committee-steering/go
    4. Share it with the SIG mailing list, lowest privileges.
    5. Share individual events with `[email protected]` to publish on the universal calendar.
 * Use existing proposal and PR process (to be documented)
-* Announce new SIG on [email protected] 
+* Announce new SIG on [email protected]
 * Leads should [subscribe to the kubernetes-sig-leads mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-leads)
 * Submit a PR to add a row for the SIG to the table in the kubernetes/community README.md file, to create a kubernetes/community directory, and to add any SIG-related docs, schedules, roadmaps, etc. to your new kubernetes/community/SIG-foo directory.
 
 #### Creating a mailing list
 
-Create a Google Group at [https://groups.google.com/forum/#!creategroup](https://groups.google.com/forum/#!creategroup), following the procedure: 
+Create a Google Group at [https://groups.google.com/forum/#!creategroup](https://groups.google.com/forum/#!creategroup), following the procedure:
 
 Each SIG must have two discussion groups with the following settings.