-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
[RFC] SIG-Auth initial charter #2000
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
cc @kubernetes/steering-committee @kubernetes/sig-auth-proposals |
sig-auth/charter.md
Outdated
@@ -0,0 +1,150 @@ | |||
# SIG Auth Governance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this jumps into structure/governance, but doesn't actually include the charter (current original charter/goals/non-goals inlined at https://github.com/kubernetes/community/blob/master/sig-auth/README.md#goals)
do we want to move that into this document? separately, those could use some updating/clarification, but probably best to tackle that in another PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the charter / mission statement / goals are more broadly useful (and interesting). What do you think of keeping that content in the README, and instead renaming this document to "governance.md"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sgtm
- Technical Leads *MAY* select additional tech leads through a [super-majority] vote amongst tech | ||
leads and chairs. This *SHOULD* be supported by a majority of SIG Members under | ||
[lazy-consensus]. | ||
- Technical Leads *MUST* remain active in the role and are automatically removed from the position |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might consider rewording this to allow for a short-term planned absence (paternity/maternity leave, sabbatical, etc) with coordination to cover responsibilities. same comment for chairs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
/assign @liggitt @ericchiang |
LGTM |
lgtm |
subproject | ||
- *MUST* proactively maintain the subproject health and status or delegate this | ||
responsibility. For actively developed projects, this *SHOULD* include setting milestone | ||
priorities, tracking release bits, and ensure adequate test coverage. For maintenance mode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/ensure/ensuring
Who is responsible for semi-regular sig/auth issue triage? |
Other questions from OOB discussion w/ @liggitt
We need to revisit the list of responsibilities with specific examples. |
# SIG Auth Governance | ||
|
||
## Roles | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the mission / scope / subprojects?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 See the SIG charter template if you need some guidance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to help brainstorm this with y'all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @tallclair @liggitt @ericchiang !
Thanks for submitting your charter. Please add a Scope
section like the one in this template: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-charter-template.md
We'd like for SIG charters to give everyone an idea of what areas of interest your SIG covers and the part of the code base or any sub projects it is responsible for. Appreciate your time!
# SIG Auth Governance | ||
|
||
## Roles | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 See the SIG charter template if you need some guidance
/unassign @ericchiang |
especially over areas for which they are the owner | ||
- *MAY* be removed if not proactively working with other Subproject Owners to fulfill | ||
responsibilities. | ||
- *MAY* decide to step down at any time and propose a replacement. Use [lazy-consensus] amongst |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a subproject has no effective leadership would it fall to majority of the SIG or the TLs of the SIG to solve/address this?
they have defined. | ||
|
||
- Proposing and making decisions | ||
- Proposals *SHOULD* be sent as [KEP] PRs and published to [kubernetes-sig-auth] as an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great to document here who needs to be set as an approver when doing a KEP. My guess is that for stuff that impacts most of the SIG it'd be a TL (with acceptance from that TL and lazy consensus around that choice). Similarly for something that is solely scoped to a subproject it'd be a subproject owner w/ lazy consensus.
Thank you for your patience as we work to your SIG charter merged. Through the process of reviewing the first 11 charters the Steering Committee (SC) found a lot of copy/paste language caused by our poorly designed initial charter template. To fix this there is a new SIG charter template which focuses on the main things we want to see in charters: scope and responsibilities. Please consider updating to this charter template and putting focus into the scope and responsibilities. SC members will focus more on a deep review of scope more than anything else and using this template will help with that focus. |
Co-authored by: @liggitt @ericchiang @tallclair
Adapted from sig-governance-template-short and sig-governance-template-long.
/sig auth