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.

[LappleApple]

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

[LappleApple]

/remove-lifecycle stale

[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-contributor-experience at kubernetes/community.
/lifecycle stale

[markjacksonfishing]

/remove-lifecycle stale

[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-contributor-experience at kubernetes/community.
/lifecycle stale

[BenTheElder]

^ the bot noise really does not help with being able to keep up with notifications 🙃

[justaugustus]

/remove-lifecycle stale
/lifecycle frozen

[justaugustus]

/assign @mrbobbytables
(from 12/6 Steering public meeting)

[mrbobbytables]

I've spoken with several of the more recent release team leads - the responsiveness of sig leadership has much improved since the issue's original creation. A lot of this can be attributed to a few practices that have been put in place by the RT:

1. Enhancements becoming opt-in
2. Creating threads and pinging leads on exception requests
3. More usage of the #chairs-and-techleads slack channel

Switching to opt-in and predominantly using Slack for reaching out to leads instead of relying on GitHub notifications seems to have done the trick. I can empathize with the leads on losing track of things in email from github =/ I'm personally not subscribed to k/k but several other areas and can at times get several hundred emails in day. I think, for better or worse Slack is our primary go-to.

Regarding some of the other original suggestions:

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.

From speaking to various sig leaders there are several that that do want to step down or have other help but feel somewhat trapped without successors - it can be difficult if you're already stretched thin to try and onboard a successor.
Steering is considering a few things that might encourage better succession planning earlier in the lead lifecycle to prevent this sort of thing from getting too far along (e.g. term/term-limits).

That said, if leads are consistently not able to fulfill their responsibilities it should be brought up with steering or the liaison for that particular sig and follow up actions can be taken.

With that - I don't think there is any direct follow-up action items from this issue outside of maybe socializing to engage steering/sig liaison when contributors see a consistent negative pattern. The other ideas are being addressed in related issues that have a more focused discussion.

ref: Better Process of selection of SIG Chairs and Technical Leads
ref: Terms and Term Limits for Chair
ref: should TechLeads be mandatory (vs not combo with Chair)

[mrbobbytables]

With no other comments and the various follow ups created in their own issue. I am going to go ahead and close this out. If we think further discussion in this specific issue is needed please feel free to reopen 👍

/cose

[BenTheElder]

cose

/close
FTFY 🙃

[k8s-ci-robot]

@BenTheElder: Closing this issue.

In response to this:

/close
FTFY 🙃

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.