1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
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.
|
