Incorporate Brian's feedback into subproject - SIG governance

Author: pwittrock

committee-steering/governance/sig-governance-template-short.md

@@ -4,32 +4,38 @@
 
 Membership for roles tracked in: <link to OWNERS file>
 
-*TODO: Write a commented template for OWNERS files*
-
 - Sig Leads
   - Run operations and processes governing the SIG
-  - Seed members established at founding
-  - Leads may decide to step down at anytime and propose a replacement.  Use
-    lazy consensus with fallback on majority vote to accept proposal.
-  - SIG may select additional leads by super majority of members
-  - Leads must remain active in the role and are automatically removed from
-    the position if they are unresponsive for > 3 months
+  - Seed members established at SIG founding
+  - Leads *MAY* decide to step down at anytime and propose a replacement.
+  - Leads *MAY* select additional leads through a [super-majority] vote.  This *SHOULD* be supported by a majority
+    of SIG members (determined through lazy consensus with fallback on voting).
+  - Leads *MUST* remain active in the role and are automatically removed from the position if they are unresponsive
+    for > 3 months and *MAY* be removed if not proactively working with other Sig Leads to fulfill responsibilities.
   - Number: 2-3
-- Technical Leads
-  - Escalation for technical discussions
-  - Set milestone priorities
-  - Seed members established at founding
-  - Leads may decide to step down at anytime and propose a replacement.  Use
-    lazy consensus with fallback on majority vote to accept proposal.
-  - SIG may select additional leads by super majority of members
-  - Leads must remain active in the role and are automatically removed from
-    the position if they are unresponsive for > 3 months
+  - Defined in [sigs.yaml]
+- *Optional Role*: SIG Technical Leads
+  - Established new and shutdown existing subprojects
+  - Resolve X-Subproject technical issues and decisions
+- Subproject Leads
+  - Scoped to a subproject or area defined in [sigs.yaml]
+  - Seed members established at subproject founding
+  - Escalation point for technical discussions in that area
+  - *MUST* Set milestone priorities
+  - *MAY* decide to step down at anytime and propose a replacement.  Use lazy consensus with fallback on
+    majority vote to accept proposal.
+  - SIG *MAY* select additional leads through a vote with a super majority of Leads.  This *SHOULD* be supported
+    by a majority of SIG members (through lazy consensus with fallback on voting).
+  - Leads *MUST* remain active in the role and are automatically removed from the position if they are unresponsive
+    for > 3 months and *MAY* be removed if not proactively working with other Project Leads to fulfill responsibilities.
   - Number: 3-5
+  - Defined in [sigs.yaml] [OWNERS] files
 - Members
-  - Maintain health of the project
-  - Build new functionality
-  - Shown sustained contributions to the area
-  - Participate in decision making
+  - *MUST* maintain health of the subproject
+  - *MUST* show sustained contributions to the area
+  - *MAY* build new functionality
+  - *MAY* participate in decision making
+  - Defined as reviewers and approvers in [OWNERS] files for subprojects
 
 ## Organizational management
 
@@ -42,39 +48,66 @@ Membership for roles tracked in: <link to OWNERS file>
 
 ### Project management
 
-- Subprojects may be created by [KEP] proposal and accepted by lazy consensus with fallback
-  on majority vote.
-  - The SIG may delegate responsibilities to local project leads
-    - Role membership must be documented in a OWNERS file
-  - Where subprojects processes diverge from the SIG governance, they must document how
-    - e.g. if subprojects release separately - they must document how release and planning
-      is performed
-
-- Release milestones
-  - Follows the kubernetes/kubernetes release milestones and schedule
-  - Priorities for upcoming release are discussed during the SIG meeting
-    following the preceding release and shared through a PR.  Priorities
-    are finalized before feature freeze.
-  - Code and artifacts are published as part of the kubernetes/kubernetes release
+#### Subproject creation
+
+---
+
+Option 1: by federation of subprojects
+
+- Subprojects may be created by [KEP] proposal and accepted by lazy consensus with fallback on majority vote of
+  subproject Leads in the SIG.  The result *SHOULD* be supported by the majority of SIG members.
+  - KEP *MUST* establish subproject leads
+  - [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with subproject leads
+  - 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
+
+Option 2: by SIG Technical leads
+
+- Subprojects may be created by [KEP] proposal and accepted by lazy consensus with fallback on majority vote of
+  SIG Technical Leads.  The result *SHOULD* be supported by the majority of SIG members.
+  - KEP *MUST* establish subproject leads
+  - [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with subproject leads
+  - 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 must define how releases are performed and milestones set.  Example follows:
+
+> - Release milestones
+>   - Follows the kubernetes/kubernetes release milestones and schedule
+>   - Priorities for upcoming release are discussed during the SIG meeting following the preceding release and
+>      shared through a PR.  Priorities are finalized before feature freeze.
+> - Code and artifacts are published as part of the kubernetes/kubernetes release
 
 ### Technical processes
 
+Subprojects of the SIG *MUST* use the following processes unless explicitly following alternatives
+they have defined.
+
 - Proposing and making decisions
   - Proposals sent as [KEP] PRs and published to googlegroup as announcement
   - Follow [KEP] decision making process
 
 - Test health
   - Canonical health of code published to <link to dashboard>
   - Consistently broken tests automatically send an alert to <link to google group>
-  - SIG members are responsible for responding to broken tests alert.  PRs that break tests
-    should be rolled back if not fixed within 24 hours (business hours).
+  - SIG members are responsible for responding to broken tests alert.  PRs that break tests should be rolled back
+    if not fixed within 24 hours (business hours).
   - Test dashboard checked and reviewed at start of each SIG meeting.  Owners assigned for any broken tests.
     and followed up during the next SIG meeting.
 
+X-Subproject decisions and test health issues should be resolved through either:
+
+- Option 1: Federation of Subproject Leads
+- Option 2: SIG Technical Leads
+
 [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://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md
+[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454
+[OWNERS]: contributors/devel/owners.md