adding more descriptive chair role and reformat

1 files changed, 140 insertions, 78 deletions

diff --git a/committee-steering/governance/sig-governance.md b/committee-steering/governance/sig-governance.md
index 1cc88601..4e39f65d 100644
--- a/committee-steering/governance/sig-governance.md
+++ b/committee-steering/governance/sig-governance.md
@@ -1,60 +1,136 @@
 # SIG Roles and Organizational Governance
 
-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 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.
 
-In order to standardize Special Interest Group efforts, create maximum transparency, and route contributors to the appropriate SIG, SIGs should follow these guidelines:
+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 the [Kubernetes Community YouTube playlist]
-- Report activity with the community via the kubernetes-dev mailing list at least once a quarter. Whichever format the SIG uses should _always_ be reported to the kubernetes-dev mailing list as this is the list the community depends on for SIG updates.  
-  - Each SIG is assigned an update during the monthly community meeting throughout the year. The meeting host will publish the notes to the kubernetes-dev mailing list with the update.  
-  - If a SIG is doing an update during KubeCon + CloudNativeCon, the SIG Chairs should ensure that a link to the recording of the video is sent to the kubernetes-dev mailing list.  
-  - YouTube presentation or mailing list update sent to the kubernetes-dev mailing list.
-- 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.
+- 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 the
+[Kubernetes Community YouTube playlist]
+- Report activity with the community via the kubernetes-dev mailing list at
+least once a quarter. Whichever format the SIG uses should _always_ be reported
+to the kubernetes-dev mailing list as this is the list the community depends on
+for SIG updates.  
+  - Each SIG is assigned an update during the monthly community meeting
+  throughout the year. The meeting host will publish the notes to the
+  kubernetes-dev mailing list with the update.  
+  - Due to limited opportunities (twice a year) at the community meeting to
+  present, your SIG will need to figure out two other options to deliver on SIG
+  updates to meet the quarterly reporting requirement:
+    a. During KubeCon + CloudNativeCon or  
+    b. A presentation or summary update sent to the kubernetes-dev
+  mailing list.
+- 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  
+- Ensure contributing instructions (CONTRIBUTING.md) are defined in the SIGs
+folder located in the Kubernetes/community repo if the groups contributor steps
+and experience are different or more in-depth than the documentation listed in
+the general [contributor guide] and [devel] folder.  
+- Help and sponsor working groups that the SIG is interested in investing in  
+- Track and identify all SIG features in the current release and [k/enhancements]
+
+The process for setting up a SIG or Working Group (WG) is listed in the
+[sig-wg-lifecycle] document.
 
 ## Roles
 
 ### Notes on 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 "Lead" refers to someone who is a member of the union
+ of a Chair, Tech Lead or Subproject Owner role. There is no one lead to any
+ Kubernetes community group. Leads have specific decision making power over some
+ part of a group and thus additional accountability. Each role is detailed below.  
 
-- Initial members are defined at the founding of the SIG or Subproject as part of the acceptance
-  of that SIG or Subproject.
-- Members *SHOULD* remain active and responsive in their Roles.
-- Members *MUST* be [community members] to be eligible to hold a leadership role
-  within a SIG.
-- Members taking an extended leave of 1 or more months *SHOULD*
-  coordinate with other members to ensure the
+- Initial roles are defined at the founding of the SIG or Subproject as part
+of the acceptance of that SIG or Subproject.
+
+#### Activity Expectations  
+- Leads *SHOULD* remain active and responsive in their Roles.
+- Leads taking an extended leave of 1 or more months *SHOULD*
+  coordinate with other leads to ensure the
   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
-  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
-  enough *active* members to get a super-majority of votes cast, then removal may occur
-  through a [super-majority] vote between Chairs, Tech Leads and Subproject Owners.
-- Membership disagreements may be escalated to the SIG Chairs.  SIG Chair membership
-  disagreements may be escalated to the Steering Committee.
-- Members *MAY* decide to step down at anytime and propose a replacement.  Use lazy consensus amongst
-  other members with fallback on majority vote to accept proposal.  The candidate *SHOULD* be supported by a
-  majority of SIG Members or Subproject Contributors (as applicable).
-- Members *MAY* select additional members through a [super-majority] vote amongst members. This
-  *SHOULD* be supported by a majority of SIG Members or Subproject Contributors (as applicable).
+- Leads going on leave for 1-3 months *MAY* work with other
+  Leads to identify a temporary replacement.
+- Leads of a role *SHOULD* remove any other leads or roles 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 Leads, or if there are
+  not enough *active* Leads to get a super-majority of votes cast, then
+  removal may occur through a [super-majority] vote between Chairs, Tech Leads
+  and Subproject Owners.
+
+#### Requirements
+- Leads *MUST* be at least a ["member" on our contributor ladder] to
+be eligible to hold a leadership role within a SIG.
+- SIGs *MAY* prefer various levels of domain knowledge depending on the
+role. This should be documented.  
+- People management interests - there's a lot of us!    
+
+#### Escalations
+- Lead membership disagreements *MAY* be escalated to the SIG Chairs. SIG Chair
+membership disagreements may be escalated to the Steering Committee.
+
+#### On-boarding and Off-boarding Leads
+- Leads *MAY* decide to step down at anytime and propose a replacement.  Use
+lazy consensus amongst other Leads with fallback on majority vote to accept
+proposal.  The candidate *SHOULD* be supported by a majority of SIG contributors
+ or the Subproject contributors (as applicable).
+- Leads *MAY* select additional leads through a [super-majority] vote
+amongst leads. This *SHOULD* be supported by a majority of SIG contributors or
+Subproject contributors (as applicable).
 
 ### Chair
 
-- Chair
-  - Run operations and processes governing the SIG
-  - Number: 2-3
-  - Membership tracked in [sigs.yaml]
+- Number: 2-3
+- Membership tracked in [sigs.yaml]  
+  - If no tech lead role is present, Chair assumes responsibilities from [#tech-lead]
+section in addition    
+
+Run operations and processes governing the SIG:
+  - *SHOULD* define how priorities and commitments are managed and delegate to
+  other leads as needed  
+  - *SHOULD* drive charter changes (including creation) to get community buy-in
+  but *MAY* delegate content creation to SIG contributors
+  - *SHOULD* identify, track, and maintain the SIGs enhancements for current
+  release and serve as point of contact for the release team, but *MAY* delegate
+   to another Lead to fulfill these responsibilities
+  - *MAY* delegate the creation of a SIG roadmap to other Leads
+  - *MUST* organize a main group meeting and make sure [sigs.yaml] is up to date
+  including subprojects and their meeting information but *SHOULD* delegate the
+  need for subproject meetings to subproject owners  
+  - *SHOULD* facilitate meetings but *MAY* delegate to other Leads or future
+  chairs/chairs in training
+  - *MUST* ensure there is a maintained CONTRIBUTING.md document in the
+  appropriate SIG folder if the contributor experience or on-boarding knowledge
+  is different than in the general [contributor guide]. *MAY* delegate to
+  contributors to create or update.
+  - *MUST* organize KubeCon/CloudNativeCon Intros and Deep Dives with CNCF Event
+   staff and approve presented content but *MAY* delegate to other contributors
+   to create material and present  
+  - *MUST* ensure meetings are recorded and made available
+  - *MUST* report activity with the community via k-dev mailing list at least
+  once a quarter (slides, video from kubecon, etc)
+  - *MUST* coordinate sponsored working group updates to the SIG and the wider
+  community  
+- *MUST* coordinate communication and be a connector with other community
+ groups like SIGs and the Steering Committee but *MAY* delegate the actual
+ communication and creation of content to other contributors where
+ appropriate  
+- *MUST* provide quarterly updates through our community channels: twice a year
+to kubernetes-dev@googlegroups.com mailing list and twice a year presenting at
+the monthly community meeting  
 
 ### Tech Lead
 
@@ -69,18 +145,20 @@ Subproject Owner Role.  (this different from a SIG or Organization Member).
 
 - Subproject Owners
   - Scoped to a subproject defined in [sigs.yaml]
-  - Seed members established at subproject founding
-  - *SHOULD* be an escalation point for technical discussions and decisions in the subproject
+  - Seed leads and contributors established at subproject founding
+  - *SHOULD* be an escalation point for technical discussions and decisions in
+  the subproject
   - *SHOULD* set milestone priorities or delegate this responsibility
   - Number: 2-3
   - Membership tracked in [sigs.yaml]
 
-### Member
+### All Leads
 
-- Members
   - *SHOULD* maintain health of at least one subproject or the health of the SIG
-  - *SHOULD* show sustained contributions to at least one subproject or to the SIG
-  - *SHOULD* hold some documented role or responsibility in the SIG and / or at least one subproject
+  - *SHOULD* show sustained contributions to at least one subproject or to the
+  SIG
+  - *SHOULD* hold some documented role or responsibility in the SIG and / or at
+  least one subproject
     (e.g. reviewer, approver, etc)
   - *MAY* build new functionality for subprojects
   - *MAY* participate in decision making for the subprojects they hold roles in
@@ -89,28 +167,11 @@ Subproject Owner Role.  (this different from a SIG or Organization Member).
 ### Security Contact
 
 - Security Contact
-  - *MUST* be a contact point for the Product Security Committee to reach out to for
-    triaging and handling of incoming issues
+  - *MUST* be a contact point for the Product Security Committee to reach out to
+   for triaging and handling of incoming issues
   - *MUST* accept the [Embargo Policy]
-  - Defined in `SECURITY_CONTACTS` files, this is only relevant to the root file in
-    the repository. Template [SECURITY_CONTACTS]
-
-## Organizational Management
-
-- SIG meets at least once every three weeks on zoom with agenda in meeting notes except November and December
-  - *SHOULD* be facilitated by chairs unless delegated to specific Members
-- SIG overview and deep-dive sessions organized for KubeCon/CloudNativeCon
-  - *SHOULD* be organized by chairs unless delegated to specific Members
-- SIG updates to Kubernetes community meeting on a regular basis
-  - *SHOULD* be presented by chairs unless delegated to specific Members
-- 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
+  - Defined in `SECURITY_CONTACTS` files, this is only relevant to the root file
+   in the repository. Template [SECURITY_CONTACTS]
 
 #### Subproject Creation
 
@@ -119,7 +180,7 @@ In addition, SIGs have the following responsibilities to SIG PM:
 Option 1: 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.
+  SIG Technical Leads.  The result *SHOULD* be supported by the majority of SIG Leads.
   - KEP *MUST* establish subproject owners
   - [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
@@ -128,7 +189,7 @@ Option 1: by SIG Technical Leads
 Option 2: by Federation of Subprojects
 
 - Subprojects may be created by [KEP] proposal and accepted by [lazy-consensus] with fallback on majority vote of
-  subproject owners in the SIG.  The result *SHOULD* be supported by the majority of members.
+  subproject owners in the SIG.  The result *SHOULD* be supported by the majority of leads.
   - KEP *MUST* establish subproject owners
   - [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
@@ -158,7 +219,7 @@ they have defined.
 - 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
+  - SIG contributors 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.
@@ -175,19 +236,20 @@ 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]: /communication/README.md
-
 [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
+[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml
 [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
+[SIG Charter process]: https://git.k8s.io/community/committee-steering/governance/README.md
+[Kubernetes Charter README]: https://git.k8s.io/community/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
-[community members]: /community-membership.md
+["member" on our contributor ladder]: /community-membership.md
 [Kubernetes Community YouTube playlist]: https://www.youtube.com/channel/UCZ2bu0qutTOM0tHYa_jkIwg
+[contributor guide]: /contributors/guide/README.md
+[devel]: /contributors/devel/README.md
+[#tech-lead]: (#Tech-Lead)