-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determine access levels for SIG subproject leads #2515
Comments
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. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
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
The text was updated successfully, but these errors were encountered: