Merge pull request #7034 from thockin/master

Add sig-net description of sig-chair role

1 files changed, 70 insertions, 0 deletions

diff --git a/sig-network/role-sig-chair.md b/sig-network/role-sig-chair.md
new file mode 100644
index 00000000..23e93cca
--- /dev/null
+++ b/sig-network/role-sig-chair.md
@@ -0,0 +1,70 @@
+# Role: SIG Chair
+
+## Background
+
+Please see the
+[standard description of a SIG chair](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md#chair),
+which does a good job describing the expectations of the more “administrative”
+aspect of being a SIG chair.
+
+## What's expected
+
+Rather than repeat the doc linked above, this doc will just add some color.
+
+The minimum effective engagement for a SIG chair is to “run the show” (really
+“make sure the show is running” - delegation is good!).  That generally means
+building an agenda for and running regular meetings, curating our
+community-facing metadata, producing annual reports and community updates,
+and acting as liaison to other groups (other SIGs and steering, mostly).
+
+This includes new-issue triage, either doing the triage or leading it (e.g. in
+the regular SIG meetings), and KEP tracking.
+
+## Above and beyond
+
+The basic expectations above, as valuable as they are, should not require a
+huge time commitment.  SIG chairs who want to have more impact and are able to
+commit more time can engage in a multitude of additional ways.  While this
+_can_ include being an active code contributor or SIG tech-lead, an effective
+SIG chair does not **need** to be a code contributor.
+
+Some concrete things that SIGs need to do, which the chair-people can
+facilitate, participate in, or even do themselves include:
+  * Active new-issue triage - go through new issues, ask for more info if
+    needed, apply labels, close or redirect “support” requests, CC people who
+    might have context, de-dup, triage-accept obvious bugs, ping submitters for
+    updates, etc.
+  * Backlog grooming - go through older issues, re-evaluate triage, de-dup,
+    aggregate similar issues, cross-link issues, link to KEPs, probe for
+    updates, etc.
+  * Manage issue and PR assignments - go through issues which are assigned to
+    people and see if progress is being made or if assignments are stale.
+  * Curate "help wanted" and "good first issue" issues - file new issues or
+    improve existing issues (e.g. by adding details or getting others to do so)
+    to enable new contributors to take them up.
+  * Manage project board(s) to organize information - things like KEPs, issues,
+    PRs, or in-progress dev efforts can usually benefit from organizing and
+    curation.
+  * Actively manage KEPs - track the KEP lifecycle, update metadata, ping KEP
+    owners for updates, contribute to KEP content and/or PRR, etc.
+  * Organize events - new member introductions, KubeCon meetups, local events,
+    etc.
+  * Actively solicit topics for regular meetings - reach out to KEP owners or
+    other efforts which could benefit from SIG discussion, or which other
+    attendees would benefit from hearing about.
+  * Docs - create, curate, edit, revise, or restructure docs (API docs, website
+    docs, etc.) related to the SIG.
+  * Check in and monitor subprojects - keep an eye out for stale / potential
+    new OWNERS to elevate or move to emeritus.
+  * ...get creative!
+
+Many of these things will need help from major technical contributors or even
+the SIG tech-lead(s).  SIG chairs are, first and foremost, facilitators, and
+the SIG TLs are their partners.
+
+## Titles vs. actions
+
+In general, a SIG chair title is something given to people who are _already
+doing the work_, rather than an invitation to begin doing it.  Existing chairs
+are expected to participate in succession planning and should seek to delegate
+tasks, in part to build up new chairs.