Determine access levels for SIG subproject leads

[justaugustus]

Now that we have subproject leads (hi @gracenng @katcosgrove @xmudrii), we have a gap in documentation and access grants (and an opportunity to allow them to review/approve additional areas).

ref: #2516

[xmudrii]

I was thinking about this, especially about how should we treat subproject leads in terms of Google Groups, GitHub, and Slack teams. I'm wondering if it makes sense to add us to the leads group (e.g. @kubernetes/sig-release-leads), because we're kind of leads and want to stay informed on all the things just like chairs and TLs. A dedicated group/team probably wouldn't make sense because I imagine it'll be rare to ping only subproject leads and not chairs/TLs. I don't know what implications on permissions this might have though.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[xmudrii]

/remove-lifecycle stale