Skip to content

Latest commit

 

History

History
70 lines (58 loc) · 3.46 KB

role-sig-chair.md

File metadata and controls

70 lines (58 loc) · 3.46 KB

Role: SIG Chair

Background

Please see the standard description of a SIG 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.