Merge pull request #3287 from parispittman/govdocs

deduping gov docs + creating a lifecycle checklist

committee-steering/governance/sig-governance.md

@@ -1,16 +1,25 @@
 # SIG Roles and Organizational Governance
 
-This charter adheres to the conventions described in the [Kubernetes Charter README].
+This charter adheres to the conventions described in the [Kubernetes Charter README]. It will be updated as needed to meet the current needs of the Kubernetes project.
 
-This document will be updated as needed to meet the current needs of the Kubernetes project.
+In order to standardize Special Interest Group efforts, create maximum transparency, and route contributors to the appropriate SIG, SIGs should follow these guidelines:
 
+- 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
+- Record meetings and make them publicly available on a YouTube playlist
+- Report activity in the weekly community meeting at least once every quarter
+- 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.
+- Use the [forums provided] as the primary means of working, communicating, and collaborating, as opposed to private emails and meetings
+
+The process for setting up a SIG or Working Group (WG) is listed in the [sig-wg-lifecycle] document.
 ## Roles
 
 ### Notes on Roles
 
-Unless otherwise stated, individuals are expected to be responsive and active within
-their roles.  Within this section "member" refers to a member of a Chair, Tech Lead or
-Subproject Owner Role.  (this different from a SIG or Organization Member).
+Within this section "member" refers to a member of a Chair, Tech Lead or
+Subproject Owner Role.  (this different from a SIG or Organization Member).  
 
 - Initial members are defined at the founding of the SIG or Subproject as part of the acceptance
   of that SIG or Subproject.
@@ -20,7 +29,7 @@ Subproject Owner Role.  (this different from a SIG or Organization Member).
   role is adequately staffed during the leave.
 - Members going on leave for 1-3 months *MAY* work with other
   members to identify a temporary replacement.
-- Members of a role *SHOULD* remove any other members that have not communicated a 
+- Members of a role *SHOULD* remove any other members that have not communicated a
   leave of absence and either cannot be reached for more than 1 month or are not
   fulfilling their documented responsibilities for more than 1 month.
   This may be done through a [super-majority] vote of members, or if there are not
@@ -49,7 +58,7 @@ Subproject Owner Role.  (this different from a SIG or Organization Member).
   - Resolve X-Subproject technical issues and decisions
   - Number: 2-3
   - Membership tracked in [sigs.yaml]
-  
+
 ### Subproject Owner
 
 - Subproject Owners
@@ -91,6 +100,11 @@ Subproject Owner Role.  (this different from a SIG or Organization Member).
 - Contributing instructions defined in the SIG CONTRIBUTING.md
 
 ### Project Management
+In addition, SIGs have the following responsibilities to SIG PM:
+- identify SIG annual roadmap
+- identify all SIG features in the current release
+- actively track / maintain SIG features within [k/enhancements]
+- attend [SIG PM] meetings, as needed / requested
 
 #### Subproject Creation
 
@@ -113,7 +127,7 @@ Option 2: by Federation of Subprojects
   - [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with subproject owners
   - Where subprojects processes differ from the SIG governance, they must document how
     - e.g. if subprojects release separately - they must document how release and planning is performed
-    
+
 Subprojects may create repos under *github.com/kubernetes-sigs* through [lazy-consensus] of subproject owners.
 
 ---
@@ -155,11 +169,17 @@ Issues impacting multiple subprojects in the SIG should be resolved by either:
   - after 3 or more months it *SHOULD* be retired
   - after 6 or more months it *MUST* be retired
 
+[SIG PM]: https://github.com/kubernetes/community/tree/master/sig-pm
+[k/enhancements]: https://github.com/kubernetes/enhancements
+[forums provided]:
+
 [lazy-consensus]: http://en.osswiki.info/concepts/lazy_consensus
 [super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote
 [KEP]: https://git.k8s.io/enhancements/keps/YYYYMMDD-kep-template.md
 [sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454
 [OWNERS]: contributors/devel/owners.md
+[SIG Charter process]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md
 [Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md
 [Embargo Policy]: https://git.k8s.io/security/private-distributors-list.md#embargo-policy
 [SECURITY_CONTACTS]: https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS
+[sig-wg-lifecycle]: /sig-wg-lifecycle.md

committee-steering/governance/wg-governance.md

@@ -4,14 +4,14 @@
 Working Groups provide a formal avenue for disparate groups to collaborate around a common problem, craft a balanced
 position, and disband. Because they represent the interests of multiple groups, they are a vehicle for consensus
 building.  If code is developed as part of collaboration within the Working Group, that code will be housed in an
-appropriate repository as described in the [repositories document][repodoc].  The merging of this code into the repository
+appropriate repository as described in the [repositories document].  The merging of this code into the repository
 will be governed by the standard policies regarding submitting code to that repository (e.g. developed within one or
 more Subprojects owned by SIGs).
 
 Because a working group is an official part of the Kubernetes project it is subject to steering committee oversight
 over its formation and disbanding.
 
-[repodoc]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md
+The tactical checklist to creation and/or retirement is found in the [SIG / WG lifeycle] document.  
 
 ## Goals of the process
 
@@ -26,7 +26,7 @@ over its formation and disbanding.
 - Changing the status of existing Working Groups/SIGs/Sub-projects
 
 ## Working Group Relationship To SIGs
-Assets owned by the Kubernetes project (e.g. code, docs, blogs, processes, etc) are owned and 
+Assets owned by the Kubernetes project (e.g. code, docs, blogs, processes, etc) are owned and
 managed by [SIGs](sig-governance.md).  The exception to this is specific assets that may be owned
 by Working Groups, as outlined below.
 
@@ -38,7 +38,7 @@ own the following types of assets:
 - Discussion Forum Groups
 
 Working Groups are distinct from SIGs in that they are intend to:
- 
+
 - facilitate collaboration across SIGs
 - facilitate an exploration of a problem / solution through a group with minimal governmental overhead
 
@@ -73,23 +73,7 @@ should eventually be reflected in a pull request on sigs.yaml:
 1. Who will chair the group, and ensure it continues to meet these requirements?
 1. Is diversity well-represented in the Working Group?
 
-Once the above questions have been answered, the pull request against sigs.yaml can be created. Once the generator
-is run, this will in turn create the OWNERS_ALIASES file, readme files, and the main SIGs list.  The minimum
-requirements for that are:
-
-- name
-- directory
-- mission statement
-- chair information
-- meeting information
-- contact methods
-- any [sig](sig-governance.md) stakeholders
-
-The pull request should be labeled with any SIG stakeholders and committee/steering. And since GitHub notifications
-are not a reliable means to contact people, an email should be sent to the mailing lists for the stakeholder SIGs,
-and the steering committee with a link to the PR. A member of the community admin team will place a /hold on it
-until it has an LGTM from at least one chair from each of the stakeholder SIGs, and a simple majority of the steering
-committee.
+Once the above questions have been answered, complete the rest of the checklist in the [SIG / WG Lifecycle] document
 
 Once merged, the Working Group is officially chartered until it either completes its stated goal, or disbands
 voluntarily (e.g. due to new facts, member attrition, change in direction, etc). Working groups should strive to
@@ -117,7 +101,8 @@ within the Working Group, and [sigs.yaml](/sigs.yaml) should be updated.
 References
 
 - [1] https://github.com/kubernetes/community/pull/1994
-- [2] https://groups.google.com/a/kubernetes.io/d/msg/steering/zEY93Swa_Ss/C0ziwjkGCQAJ 
+- [2] https://groups.google.com/a/kubernetes.io/d/msg/steering/zEY93Swa_Ss/C0ziwjkGCQAJ
 
 
-[repository document]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md
+[SIG / WG Lifecycle]: /sig-wg-lifecycle.md
+[repositories document]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md

governance.md

@@ -6,18 +6,22 @@ The Kubernetes community adheres to the following principles:
 * Open: Kubernetes is open source. See repository guidelines and CLA, below.
 * Welcoming and respectful: See Code of Conduct, below.
 * Transparent and accessible: Work and collaboration should be done in public. See SIG governance, below.
-* Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, [scope](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/), and [design principles](contributors/design-proposals/architecture/principles.md).
+* Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, [scope], and [design principles].
 
 # Code of Conduct
 
-The Kubernetes community abides by the [Kubernetes code of conduct](/code-of-conduct.md). Here is an excerpt:
+The Kubernetes community abides by the [Kubernetes code of conduct]. Here is an excerpt:
 
 _As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities._
 
 As a member of the Kubernetes project, you represent the project and your fellow contributors.
 We value our community tremendously and we'd like to keep cultivating a friendly and collaborative
 environment for our contributors and users. We want everyone in the community to have
-[positive experiences](https://www.cncf.io/blog/2016/12/14/diversity-scholarship-series-one-software-engineers-unexpected-cloudnativecon-kubecon-experience).
+[positive experiences].
+
+# Values
+
+[We have them!]
 
 # Community membership
 
@@ -83,6 +87,10 @@ community.
 See [sig governance] for more details about current SIG operating
 mechanics, such as mailing lists, meeting times, etc.
 
+More information:  
+[SIG Governance Requirements]  
+[SIG Lifecycle] - for a tactical checklist on creation and retirement  
+
 ### Subprojects
 
 Specific work efforts within SIGs are divided into **subprojects**.
@@ -97,10 +105,9 @@ 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).
+Subprojects for each SIG are documented in [sigs.yaml].
 
 ## Working Groups
 
@@ -115,7 +122,7 @@ forming a Working Group.
 See [working group governance] for more details about forming and disbanding
 Working Groups.
 
-Working groups are documented in [sigs.yaml](sigs.yaml).
+Working groups are documented in [sigs.yaml].
 
 
 ## Committees
@@ -134,15 +141,15 @@ charter.
 Some topics have long term relevance to large groups of Kubernetes users, but
 do not have clear deliverables or ownership of parts of the Kubernetes
 code base. As such they are neither good fits for SIGs or Working Groups.
-An example of such a topic might be continuous delivery to Kubernetes. 
+An example of such a topic might be continuous delivery to Kubernetes.
 
 Though their central goal is not a a deliverable piece of work, as contributing
 members of the community user groups are expected to work with SIGs
 to either identify friction or usability issues that need to be addressed,
 or to provide or improve documentation in their area of expertise. However
 these activities are covered under general code contributions to the relevant
 SIGs (e.g. SIG Docs) rather than as part of the user group. These contributions
-are expected to be more incremental and ad-hoc versus the more targeted 
+are expected to be more incremental and ad-hoc versus the more targeted
 output of a user group.
 
 User groups function as a centralized resource to facilitate communication
@@ -152,8 +159,8 @@ form working groups under the auspices of some SIG for such work. Likewise
 they shouldn't take ownership of anything in the Kubernetes process, as
 that is a role for SIGs.
 
-To facilitate discoverability and engagement, 
-user groups are documented in [sigs.yaml](sigs.yaml)
+To facilitate discoverability and engagement,
+user groups are documented in [sigs.yaml]
 
 ## Cross-project Communication and Coordination
 
@@ -192,12 +199,19 @@ Note that "Kubernetes incubator" process has been deprecated in favor of the new
 
 All contributors must sign the CNCF CLA, as described [here](CLA.md).
 
+[positive experiences]: https://www.cncf.io/blog/2016/12/14/diversity-scholarship-series-one-software-engineers-unexpected-cloudnativecon-kubecon-experience
+[sigs.yaml]: /sigs.yaml
+[SIG Lifecycle]: /sig-wg-lifecycle
+[We have them!]: /values.md
+[Kubernetes code of conduct]: /code-of-conduct.md
+[design principles]: /contributors/design-proposals/architecture/principles.md
+[scope]: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
 [community membership]: /community-membership.md
-[sig governance]: /sig-governance.md
+[sig governance]: /committee-steering/sig-governance.md
 [owners]: /community-membership.md#subproject-owner
 [sig charter process]: /committee-steering/governance/README.md
 [short template]: /committee-steering/governance/sig-governance-template-short.md
 [kubernetes repository guidelines]: /github-management/kubernetes-repositories.md
 [working group governance]: /committee-steering/governance/wg-governance.md
-
+[SIG Governance Requirements]: /committee-steering/governance/sig-governance-requirements.md
 [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]()