Community: Responsiveness of SIG Chairs needs improvement

[guineveresaenger]

Hi Kubies,

I am the 1.17 Release Team Lead and I'm here to tell you that my team has been amazing throughout the release. But future release teams need your help!

We have had a really difficult time getting a response from some SIG-chairs on important release related issues via the SIG Chairs' mailing list. Almost every release team lead has had to go hunt down individuals via Slack, and sometimes even Twitter(!) DM to get a response.

Conferring with previous release leads, SIG-Architecture, and SIG-contributor-experience, this has been a problem for a while.

The responsibility for communication should be shared, and currently, it is not.

This communication lag delays releases and creates needless legwork for the Release Team and other inter-SIG efforts.

The following things are true to the best of my knowledge

• The SIG Chair mailing list is the canonical way of contacting the SIG chairs.
• It is the SIG Chairs' responsibility to read and respond in a timely matter to action items on the SIG chair mailing list.
• Being a Kubernetes SIG Chair is not only an honor and a duty, it is also beneficial, and in some cases intrinsically related to, a contributor's career. (Some folks are directly being paid by their employers to chair a SIG or Subproject.)

It is, therefore, my suggestion that there should be consequences for not responding to communications in the mailing list in a timely manner.

I welcome suggestions from the community. Here are some ideas for discussion:

• Chairs "ack" any item marked "ACTION REQUIRED" just so collaborators know the message reached you
• Any SIG that is not responding in a timely fashion will be automatically refused for exception requests during a release cycle
• Chairs that do not respond in a timely fashion will be removed as chairs. If you do not have the time, you should not do the job. It's a lot of leg work - perhaps give a more junior contributor a turn.

I really, really do not want to escalate this to Steering. I also want to express my 🎉 sincerest thanks 🎉 to all the SIG leads that have been responsive and helpful around project-wide efforts like the release process and the contributor summits. You exemplify what everyone should aspire to be.

/sig contributor-experience
/area community-management
/cc @justaugustus
/cc @geekygirldawn
/cc @parispittman
/cc @castrojo

[guineveresaenger]

/sig api-machinery
/sig apps
/sig architecture
/sig auth
/sig autoscaling
/sig cli
/sig cloud-provider
/sig cluster-lifecycle
/sig docs
/sig instrumentation
/sig multicluster
/sig network
/sig node
/sig onprem
/sig pm
/sig release
/sig scalability
/sig scheduling
/sig service-catalog
/sig storage
/sig testing
/sig ui
/sig usability
/sig windows

[castrojo]

Many of these release requirements are listed in the governance: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md

More broadly it's not just the release team that has this problem. A quick scan of the YouTube playlists, SIG Meeting minutes, and other transparency goals are simply not being met. It's become a chore for the community meeting host to get SIGs to even commit to their once a quarter community report, with some meetings resulting in 0 of the 3 required SIGs to even show up to the meeting.

We've also increased overhead to run things like the contributor summit by having to have volunteers cross check registration with org membership only to find that people in leadership positions are not reading the information required to run events of this complexity smoothly.

[jeefy]

This is my hot-take when it comes to SIG-Chairs and the health of the project.

• SIG-Chairs should have a term limit and an effort limit.
• SIGs should have no more than three chairs. The rotations should be staggered so 4-6-12mo depending on 3-2-1 chairs, rotate.
• They should have someone shadow them for the last two months of their term (that is already in the OWNERs file as an approver)
• While a SIG-Chair, they should not take on leadership of another area of the project (Another SIG, Release Lead, Steering, COC)
• At the end of their term, they Emeritus themselves. If the new chair needs to step down unexpectedly, the emeritus can step in and begin the new shadow process.

Benefits?

• SIGs now have chairs whose primary focus is that SIG and not five other things
• Chairs rotating out prevents burnout. Chairs rotating in are fresh and can help maintain SIG velocity
• We promote mentoring and dogfood our own processes

We have the OWNER promotion process, but we don't explicitly mentor people within a SIG (per se) and maybe that needs to change. The release team has a really good process, and it shows. Shadowing like this is tried and true.

Feel free discuss/ignore/laugh. This is a bunch of ideas rolled up into a single idea-burrito. While I think it's all valid, I want it to promote other ideas/solutions to the wide range of problems we face.

I also don't take credit for all of this, parts have been discussed with and came from various others.

[onlydole]

I like the provisions outlined in your hot-take, @jeefy. :smile:

Making an effort to distribute the load of a SIG chair and encourage growth with the shadow process would be great to see! I especially like the idea of limiting the focus of the SIG chair role to only the SIG chair role.

[parispittman]

+1 to jeff (lol i did say bob first)

[lavalamp]

I was a chair until just recently; chairs are kind of DOSed with communication, at least for me that is usually the cause of non-responsiveness.

I agree with the idea of requiring occasional confirmation to stay in a role, whether that's a term limit or something else. The point is to set the expectation of transiency. It's socially difficult for people to say "bad" things about people, like they're not being a good chair or whatever. Making the position time bounded in some way removes the need for someone to take the social risk of speaking up. We don't necessarily have to go all the way to term limits, just requiring an annual reconfirmation of some sort is probably going to get a large amount of the benefit.

I think we need to grade SIGs (not the chairs--no need to make it personal) on how many of the SIG's obligations are being carried out. A poor grade might be a good reason to change chairs. Without some objective measure, chair is just a popularity contest, which is not good (seeking popularity leaves you less time to be a good chair).

[timothysc]

As a chair, I see it as a responsibility to federate, or bow out, where necessary ^.

[mattfarina]

SIG-Chairs should have a term limit and an effort limit.

This has come up in the past. The problem is finding replacements for the people if they were term limited out.

Kubernetes contributions are going down. Some of this is because things are being broken out into other repos and some of this is because Kubernetes is stable enough that people are moving on to other projects (part or all of the time) or are working on things to make their companies money with Kubernetes.

This goes along with something we have not been good at. That is building up more contributors. This can require giving direction, providing high quality reviews, and other mentor/maintainer tasks. Note, this view was shared with me rather than being something I noticed.

If we want more responsive chairs we need more people capable of being a chair and people who have replacements or successions willing to hand off to them.

[lavalamp]

As a chair, I see it as a responsibility to federate, or bow out, where necessary

Not everyone sees it the same way; also, at some level of overloadedness people lose the ability to load shed / gracefully bow out.

The problem is finding replacements for the people if they were term limited out.

This is a general problem, not a problem with term limits. Maybe we should require 1-2 active chairs and 1-3 seconds / chairs-in-training / shadows.

[BenTheElder]

Kubernetes contributions are going down. Some of this is because things are being broken out into other repos and some of this is because Kubernetes is stable enough that people are moving on to other projects (part or all of the time) or are working on things to make their companies money with Kubernetes.

IMHO at least some of this is related to the difficulty to merge unless you know the right active people to poke and jump through various other hoops ... which in part stems from responsiveness of OWNERS, a somewhat-related but separate problem.

EDIT: xref #3753

[parispittman]

we also don't ask people either re: pipeline for chairs. (example: quarterly asks to mailing lists about open roles coming up, currently open, etc.). I don't do enough of this but when I do (and I see others, too) we get a ton of folks who step forward. term limits can help be a forcing function here to succession planning and having these conversations with contributors.

[justaugustus]

/remove-sig pm

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nikhita]

Steering is conducting annual health check reports to help with this - https://github.com/kubernetes/community/blob/master/committee-steering/governance/annual-reports.md

/remove-lifecycle stale

[jayunit100]

Why not just have rotating chairs ? The ASF does this quite a bit , and it seems to work even on projects which are highly understaffed. In my experience on that side - new chairs tend to add a lot of enthusiasm and vigor to the community side of a group since they're excited about learning the ropes etc.

[alejandrox1]

I think this issue in itself is a good example of the problem statement.

What follows is my perspective (biased in many ways)

Some of the actionable tings that were proposed in this issue are the following:

I welcome suggestions from the community. Here are some ideas for discussion:

• Chairs "ack" any item marked "ACTION REQUIRED" just so collaborators know the message reached you
  ...

It ultimately comes down to "team X needs acknowledgement from leads that they know about information Y".
And hopefully that information would be passed along in the respective SIG meetings.
All with the hope that deadlines won't be a surprise and that the community will be well informed on all things.

On chair lifecycle and other considerations I will not offer a comment at this time because I want to cycle back on this issue to the need to standardize communication channels between release team and community and to have an explicit ACK from leads that they see information coming out of the release team and that information is being passed down to all SIG members.

[mrbobbytables]

looping in steering for review 👍 It might be handled by the sig check ins.

[BenTheElder]

FWIW I've personally found things like the heavily moderated #chairs-and-techleads channel extremely helpful for being able to keep up with important notices since starting as SIG Testing chair.

As long as critical communications are kept in these high signal-to-noise environments, keeping up has not been problematic for me at least.

On the other hand, I frequently see people reach out via other means, in which I'm innundated with messages regardless of chair status and may not be as responsive. E.G. @ mentioning a SIG team on github is near-useless, the signal to noise ratio is abysmal.

EDIT: The sig-leads list has also been pretty quiet, at least recently I'm not seeing evidence of things requiring a response going unresponded, but it has been a year since this issue was filed.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[jayunit100]

@LappleApple has this issue floated into the zombie zone or should it be revitalized?

[LappleApple]

Heya @jayunit100: We're working on some things in the Enhancements subproject that point to this, and I believe other groups like SteerCo have kept this in mind as well but I'll defer to them to give you the details. :)

[LappleApple]

@jayunit100 That said, if you have ideas or want to help out here then that's totally great.

[LappleApple]

/remove-lifecycle stale