Merge pull request #1800 from pwittrock/gov-requirements

SIG Governance Requirements and Recommendations

2 files changed, 112 insertions, 0 deletions

diff --git a/committee-steering/governance/README.md b/committee-steering/governance/README.md
new file mode 100644
index 00000000..c6fcdad0
--- /dev/null
+++ b/committee-steering/governance/README.md
@@ -0,0 +1,35 @@
+# SIG Governance Template
+
+## Goals
+
+The following documents outline recommendations and requirements for SIG governance structure and provide
+template documents for SIGs to adapt.  The goals are to define the baseline needs for SIGs to self govern
+and organize in a way that addresses the needs of the core Kubernetes project.
+
+The documents are focused on:
+
+- Outlining organizational responsibilities
+- Outlining organizational roles
+- Outlining processes and tools
+
+Specific attention has been given to:
+
+- The role of technical leadership
+- The role of operational leadership
+- Process for agreeing upon technical decisions
+- Process for ensuring technical assets remain healthy
+
+## How to use the templates
+
+When developing or modifying a SIG governance doc, the intention is for SIGs to use the templates (*forthcoming*) as
+a common set of options SIGs may choose to incorporate into their own governance structure.  It is recommended that
+SIGs start by looking at the [Recommendations and requirements] for SIG governance docs and consider what structure
+they think will work best for them before pulling items from the templates.
+
+The expectation is that SIGs will pull and adapt the options in the templates to best meet the needs of the both the SIG
+and project.
+
+- [Recommendations and requirements]
+
+[Recommendations and requirements]: sig-governance-requirements.md
+
diff --git a/committee-steering/governance/sig-governance-requirements.md b/committee-steering/governance/sig-governance-requirements.md
new file mode 100644
index 00000000..2d6e5fa2
--- /dev/null
+++ b/committee-steering/governance/sig-governance-requirements.md
@@ -0,0 +1,77 @@
+# SIG Governance Requirements
+
+## Goals
+
+This document outlines the recommendations and requirements for defining SIG and subproject governance.
+
+This doc uses [rfc2119](https://www.ietf.org/rfc/rfc2119.txt) to indicate keyword requirement levels.
+Sub elements of a list inherit the requirements of the parent by default unless overridden.
+
+## Checklist
+
+Following is the checklist of items that should be considered as part of defining governance for
+any subarea of the Kubernetes project.
+
+### Roles
+
+- *MUST* enumerate any roles within the SIG and the responsibilities of each
+- *MUST* define process for changing the membership of roles
+  - When and how new members are chosen / added to each role
+  - When and how existing members are retired from each role
+- *SHOULD* define restrictions / requirements for membership of roles
+- *MAY* define target staffing numbers of roles
+
+### Organizational management
+
+- *MUST* define when and how collaboration between members of the SIG is organized
+  - *SHOULD* define how periodic video conference meetings are arranged and run
+  - *SHOULD* define how conference / summit sessions are arranged
+  - *MAY* define periodic office hours on slack or video conference
+
+- *MAY* define process for new community members to contribute to the area
+  - e.g. read a contributing guide, show up at SIG meeting, message the google group
+
+### Project management
+
+- *MUST* define how subprojects are managed if at all
+  - When and how new subprojects are created
+  - Roles within subprojects
+- *MUST* define how milestones / releases are set
+  - How target dates for milestones / releases are proposed and accepted
+  - What priorities are targeted for milestones
+  - The process for publishing a release
+- *SHOULD* define how priorities / commitments are managed
+  - How priorities are determined
+  - How priorities are staffed
+
+### Technical processes
+
+For areas owning technical assets only.
+
+- *MUST* define how technical decisions are communicated and made within the SIG or project
+  - Process for proposal, where and how it is published and discussed, when and how a decision is made
+    (e.g. [KEP] process)
+  - Who are the decision makers on proposals (e.g. anyone in the world can block, just reviewers on the PR,
+    just approvers in OWNERs, etc)
+  - How disagreements are resolved within the area (e.g. discussion, fallback on voting, escalation, etc)
+  - How and when disagreements may be escalated
+  - *SHOULD* define expectations and recommendations for proposal process (e.g. escalate if not progress towards
+    resolution in 2 weeks)
+  - *SHOULD* define a level of commitment for decisions that have gone through the formal process
+    (e.g. when is a decision revisited or reversed)
+
+- *MUST* How technical assets of project remain healthy and can be released
+  - Publicly published signals used to determine if code is in a healthy and releasable state
+  - Commitment and process to *only* release when signals say code is releasable
+  - Commitment and process to ensure assets are in a releasable state for milestones / releases
+    coordinated across multiple areas / subprojects (e.g. the Kubernetes OSS release)
+  - *SHOULD* define target metrics for health signal (e.g. broken tests fixed within N days)
+  - *SHOULD* define process for meeting target metrics (e.g. all tests run as presubmit, build cop, etc)
+
+[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus
+[super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote
+[warnocks-dilemma]: http://communitymgt.wikia.com/wiki/Warnock%27s_Dilemma
+[slo]: https://en.wikipedia.org/wiki/Service_level_objective
+[steering-commitee]: https://github.com/kubernetes/steering#contact
+[business-operations]: http://www.businessdictionary.com/definition/business-operation.html
+[KEP]: https://kubernetes.io/docs/imported/community/keps/
\ No newline at end of file