# 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.
