kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #7204 from mrbobbytables/clean-up-gov 

Clean up SIG Governance
This commit is contained in:
Kubernetes Prow Robot 2023-03-28 18:23:24 -07:00 committed by GitHub
parent c3904aebad 50b57c5eca
commit 8beffa2067
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 143 additions and 161 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

278
committee-steering/governance/sig-governance.md
View File

@ -1,35 +1,32 @@
# SIG Roles and Organizational Governance # SIG Roles and Organizational Governance
This charter adheres to the conventions described in the [Kubernetes Charter README]. This charter adheres to the conventions described in the
It will be updated as needed to meet the current needs of the Kubernetes project. [Kubernetes Charter README]. It will be updated as needed to meet the current
needs of the Kubernetes project.
In order to standardize Special Interest Group efforts, create maximum To standardize Special Interest Group efforts, create maximum transparency, and
transparency, and route contributors to the appropriate SIG, SIGs should follow route contributors to the appropriate SIG; SIGs should follow these guidelines:
these guidelines: - Have an approved Charter [SIG charter process].
- Have an approved Charter [SIG charter process]
- Meet regularly, at least for 30 minutes every 3 weeks, except November and - Meet regularly, at least for 30 minutes every 3 weeks, except November and
December December.
- Keep up-to-date meeting notes, linked from the SIG's page in the community - Keep up-to-date meeting notes, linked from the SIG's page in the community
repo repo.
- Record meetings and make them publicly available on the - Record meetings and make them publicly available on the
[Kubernetes Community YouTube playlist] [Kubernetes Community YouTube playlist].
- Report activity with the community via the dev@kubernetes.io mailing list at - Record activity and complete the [annual report].
least once a year. - Participate in release planning meetings, retrospectives, and burndown
- This is separate from the [annual report]. meetings, as needed.
- Participate in release planning meetings and retrospectives, and burndown - Ensure related work happens in a project-owned GitHub org and repository,
meetings, as needed with code and tests explicitly owned and supported by the SIG, including
- Ensure related work happens in a project-owned github org and repository, with issue triage, PR reviews, test-failure response, bug fixes, etc.
code and tests explicitly owned and supported by the SIG, including issue - Use the [forums provided] as the primary means of working, communicating,
triage, PR reviews, test-failure response, bug fixes, etc. and collaborating, as opposed to private emails and meetings.
- Use the [forums provided] as the primary means of working, communicating, and
collaborating, as opposed to private emails and meetings
- Ensure contributing instructions (CONTRIBUTING.md) are defined in the SIGs - Ensure contributing instructions (CONTRIBUTING.md) are defined in the SIGs
folder located in the Kubernetes/community repo if the groups contributor steps folder located in the Kubernetes/community repo if the groups contributor
and experience are different or more in-depth than the documentation listed in steps and experience are different or more in-depth than the documentation
the general [contributor guide] and [devel] folder. listed in the general [contributor guide] and [devel] folder.
- Help and sponsor working groups that the SIG is interested in investing in - Help and sponsor working groups that the SIG is interested in investing in
- Track and identify all SIG features in the current release and [k/enhancements] - Track and identify all [KEPs] and other project enhancements.
The process for setting up a SIG or Working Group (WG) is listed in the The process for setting up a SIG or Working Group (WG) is listed in the
[sig-wg-lifecycle] document. [sig-wg-lifecycle] document.
@ -38,83 +35,90 @@ The process for setting up a SIG or Working Group (WG) is listed in the
### Notes on Roles ### Notes on Roles
Within this section "Lead" refers to someone who is a member of the union Within this section, "Lead" refers to someone who is a member of the union of a
of a Chair, Tech Lead, or Subproject Owner role. Leads may, and frequently do Chair, Tech Lead, or Subproject Owner role. Leads may, and frequently do, hold
hold more than one role. There is no one lead to any Kubernetes community more than one role. There is no singular lead to any Kubernetes community
group. Leads have specific decision making power over some part of a group group. Leads have specific decision-making power over some part of a group and
and thus additional accountability. Each role is detailed below. thus, additional accountability. Each role is detailed below.
- Initial roles are defined at the founding of the SIG or Subproject as part
of the acceptance of that SIG or Subproject. Initial roles are defined at the founding of the SIG or Subproject as part of
the acceptance of that SIG or Subproject.
### Leads
#### Activity Expectations #### Activity Expectations
- Leads *SHOULD* remain active and responsive in their Roles. - Leads *SHOULD* remain active and responsive in their Roles.
- Leads taking an extended leave of 1 or more months *SHOULD* coordinate with other leads to ensure the role is adequately staffed during the leave. - Leads taking an extended leave of 1 or more months *SHOULD* coordinate with
- Leads going on leave for 1-3 months *MAY* work with other Leads to identify a temporary replacement. other leads to ensure the role is adequately staffed during their leave.
- Leads of a role *SHOULD* remove any other leads or roles that have not communicated a leave of absence and either cannot be reached for more than 1 month or are not fulfilling their documented responsibilities for more than 1 month. - Leads going on leave for 1-3 months *MAY* work with other Leads to identify a
- This may be done through a [super-majority] vote of Leads. If there are not enough *active* Leads, then a [super-majority] vote between Chairs, Tech Leads and Subproject Owners may decide the removal of the Lead. temporary replacement.
- Leads *SHOULD* remove any other leads that have not communicated a leave of
absence and either cannot be reached for more than one month or are not
fulfilling their documented responsibilities for more than one month.
- Removal may be done through a [super-majority] vote of the active Leads.
- If there is not enough *active* Leads, then a [super-majority] vote
between the remaining active Chairs, Tech Leads, and Subproject Owners may
decide the removal of the Lead.
#### Requirements #### Requirements
- Leads *MUST* be at least a ["member" on our contributor ladder] to - Leads *MUST* be at least a ["member" on our contributor ladder] to be
be eligible to hold a leadership role within a SIG. eligible to hold a leadership role within a SIG.
- SIGs *MAY* prefer various levels of domain knowledge depending on the - SIGs *MAY* prefer various levels of domain knowledge depending on the role.
role. This should be documented. This should be documented.
- People management interests - there's a lot of us! - Interest or skills in people management.
#### Escalations #### Escalations
- Lead membership disagreements *MAY* be escalated to the SIG Chairs. SIG Chair - Lead membership disagreements *MAY* be escalated to the SIG Chairs. SIG Chair
membership disagreements may be escalated to the Steering Committee. membership disagreements may be escalated to the Steering Committee.
#### On-boarding and Off-boarding Leads #### On-boarding and Off-boarding Leads
- Leads *MAY* decide to step down at anytime and propose a replacement. Use - Leads *MAY* decide to step down at anytime and propose a replacement. Use
lazy consensus amongst other Leads with fallback on majority vote to accept lazy consensus amongst the other Leads with fallback on majority vote to
proposal. The candidate *SHOULD* be supported by a majority of SIG contributors accept the proposal. The candidate *SHOULD* be supported by a majority of
or the Subproject contributors (as applicable). SIG contributors or Subproject contributors (as applicable).
- Leads *MAY* select additional leads through a [super-majority] vote - Leads *MAY* select additional leads through a [super-majority] vote amongst
amongst leads. This *SHOULD* be supported by a majority of SIG contributors or leads. This *SHOULD* be supported by a majority of SIG contributors or
Subproject contributors (as applicable). Subproject contributors (as applicable).
### Chair #### Chair
- Number: 2+ - Number: 2+
- Membership tracked in [sigs.yaml] - Membership tracked in [sigs.yaml]
- *SHOULD* define how priorities and commitments are managed. *MAY* delegate to
In addition, run operations and processes governing the SIG: other leads as needed.
- *SHOULD* drive charter changes (including creation) to get community buy-in
- *SHOULD* define how priorities and commitments are managed and delegate to other leads as needed but *MAY* delegate content creation to SIG contributors.
- *SHOULD* drive charter changes (including creation) to get community buy-in but *MAY* delegate content creation to SIG contributors
- *MUST* in conjunction with the Tech Leads identify, track, and maintain the - *MUST* in conjunction with the Tech Leads identify, track, and maintain the
metadata of the SIGs enhancements for the current release and serve as metadata of the SIGs enhancements for the current release and serve as
point of contact for the release team, but *MAY* delegate to other point of contact for the release team, but *MAY* delegate to other
contributors to fulfill these responsibilities contributors to fulfill these responsibilities.
- *MAY* delegate the creation of a SIG roadmap to other Leads - *MAY* delegate the creation of a SIG roadmap to other Leads.
- *MUST* organize a main group meeting and make sure [sigs.yaml] is up to date - *MUST* organize a main group meeting and make sure [sigs.yaml] is up to date,
including subprojects and their meeting information but *SHOULD* delegate the including subprojects and their meeting information, but *SHOULD* delegate
need for subproject meetings to subproject owners the need for subproject meetings to subproject owners.
- *SHOULD* facilitate meetings but *MAY* delegate to other Leads or future - *SHOULD* facilitate meetings but *MAY* delegate to other Leads or future
chairs/chairs in training chairs/chairs in training.
- *MUST* ensure there is a maintained CONTRIBUTING.md document in the - *MUST* ensure there is a maintained CONTRIBUTING.md document in the
appropriate SIG folder if the contributor experience or on-boarding knowledge appropriate SIG folder if the contributor experience or on-boarding knowledge
is different than in the general [contributor guide]. *MAY* delegate to is different than in the general [contributor guide]. *MAY* delegate to
contributors to create or update. contributors to create or update.
- *MUST* organize KubeCon/CloudNativeCon Intros and Deep Dives with CNCF Event - *MUST* organize KubeCon/CloudNativeCon Intros and Deep Dives with CNCF Event
staff and approve presented content but *MAY* delegate to other contributors staff and approve presented content but *MAY* delegate to other contributors.
to create material and present - *MUST* ensure meetings are recorded and made available.
- *MUST* ensure meetings are recorded and made available - *MUST* coordinate sponsored working group updates to the SIG and the wider
- *MUST* coordinate sponsored working group updates to the SIG and the wider community.
community
- *MUST* coordinate communication and be a connector with other community - *MUST* coordinate communication and be a connector with other community
groups like SIGs and the Steering Committee but *MAY* delegate the actual groups like SIGs and the Steering Committee but *MAY* delegate the actual
communication and creation of content to other contributors where communication and creation of content to other contributors where appropriate.
appropriate - *MUST* create the yearly [annual report] for the group but *SHOULD* get help
- *MUST* present yearly [annual report] for the group but *SHOULD* get help with with curation from other SIG participants.
curation from other SIG participants
### Tech Lead #### Tech Lead
- Number: 2+ - Number: 2+
- Membership tracked in [sigs.yaml] - Membership tracked in [sigs.yaml]
@ -132,41 +136,39 @@ curation from other SIG participants
Additional information on the Tech Lead role can be found in Additional information on the Tech Lead role can be found in
[technical-lead.md]; within the [Chair & TL Contributor Documentation]. [technical-lead.md]; within the [Chair & TL Contributor Documentation].
### Subproject Owner #### Subproject Owner
- Subproject Owners - Number: 2+
- Scoped to a subproject defined in [sigs.yaml] - Scoped to a subproject defined in [sigs.yaml]
- Seed leads and contributors established at subproject founding - Seed leads and contributors established at subproject founding
- *SHOULD* be an escalation point for technical discussions and decisions in - *SHOULD* be an escalation point for technical discussions and decisions in
the subproject the subproject
- *SHOULD* set milestone priorities or delegate this responsibility - *SHOULD* set milestone priorities or delegate this responsibility
- Number: 2-3 - Membership tracked in [sigs.yaml] via links to OWNERS files
- Membership tracked in [sigs.yaml]
### All Leads #### All Leads
- *SHOULD* maintain health of at least one subproject or the health of the SIG - *SHOULD* maintain health of their SIG or subproject
- *SHOULD* show sustained contributions to at least one subproject or to the - *SHOULD* show sustained contributions to at least one subproject or the the
SIG SIG at large.
- *SHOULD* hold some documented role or responsibility in the SIG and / or at - *SHOULD* hold some documented role or responsibility in the SIG and / or at
least one subproject least one subproject (e.g. reviewer, approver, etc)
(e.g. reviewer, approver, etc)
- *MAY* build new functionality for subprojects - *MAY* build new functionality for subprojects
- *MAY* participate in decision making for the subprojects they hold roles in - *MAY* participate in decision making for the subprojects they hold roles in
- Includes all reviewers and approvers in [OWNERS] files for subprojects - *MUST* take an [Inclusive Open Source Community Orientation course] in
- *MUST* take an [Inclusive Open Source Community Orientation course] in support of our community values support of our community values within 30 days from the date of their
within 30 days from the date of their appointment. appointment.
### Security Contact ### Security Contact
- Security Contact - Defined in `SECURITY_CONTACTS` at the root of the repository. Example:
- *MUST* be a contact point for the Product Security Committee to reach out to [SECURITY_CONTACTS]
- *MUST* be a contact point for the Security Response Committee to reach out to
for triaging and handling of incoming issues for triaging and handling of incoming issues
- *MUST* accept the [Embargo Policy] - *MUST* accept the [Embargo Policy]
- Defined in `SECURITY_CONTACTS` files, this is only relevant to the root file
in the repository. Template [SECURITY_CONTACTS]
### Other Roles ### Other Roles
This governance document outlines the required roles for SIGs: Chair and Tech This governance document outlines the required roles for SIGs: Chair and Tech
Lead; however, SIGs are allowed to operate how they see fit outside of minimum Lead; however, SIGs are allowed to operate how they see fit outside of minimum
governance requirements, including defining more roles to sustain the group. If governance requirements, including defining more roles to sustain the group. If
@ -185,75 +187,55 @@ Example of SIG roles created to help operations:
- [Marketing Council] - [Marketing Council]
Other roles... Other roles...
- *MUST* be tracked on the SIGs README with a link to the role definition - *MUST* be tracked on the SIGs README with a link to the role definition.
- *MUST* have the Steering Committees approval to proceed with roles that assume - *MUST* have the Steering Committees approval to proceed with roles that
duties from Chairs and/or Tech Leads on a non-temporary basis assume duties from Chairs and/or Tech Leads on a non-temporary basis.
- *SHOULD* be documented in SIG charters if the role has delegation away from a - *SHOULD* be documented in SIG charters if the role has delegation away from a
sig-governance.md listed role sig-governance.md listed role.
- *SHOULD* be sent to dev@kubernetes.io for awareness as a notice - *SHOULD* be sent to dev@kubernetes.io for awareness as a notice with a lazy
and a lazy consensus period when they are newly created consensus period when they are newly created
- *MAY* Fill in for another named role on a temporary basis - *MAY* Fill in for another named role on a temporary basis
#### Subproject Creation
---
Option 1: by SIG Technical Leads ## Subprojects
- Subprojects may be created by [KEP] proposal and accepted by [lazy-consensus] with fallback on majority vote of ### Subproject Creation
SIG Technical Leads. The result *SHOULD* be supported by the majority of SIG Leads.
- KEP *MUST* establish subproject owners
- [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with subproject owners
- Where subprojects processes differ from the SIG governance, they must document how
- e.g. if subprojects release separately - they must document how release and planning is performed
Option 2: by Federation of Subprojects Subprojects may be created with a simple majority vote of SIG Technical Leads.
- [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS]
files with subproject owners.
- Where subprojects processes differ from the SIG governance, they must
document how. e.g. if subprojects release separately - they must document
how release and planning is performed
- Subprojects may be created by [KEP] proposal and accepted by [lazy-consensus] with fallback on majority vote of ### Subproject Requirements
subproject owners in the SIG. The result *SHOULD* be supported by the majority of leads.
- KEP *MUST* establish subproject owners
- [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with subproject owners
- Where subprojects processes differ from the SIG governance, they must document how
- e.g. if subprojects release separately - they must document how release and planning is performed
Subprojects may create repos under *github.com/kubernetes-sigs* through [lazy-consensus] of subproject owners. Subprojects broadly fall into two categories, those that are directly part
of [Kubernetes] core and those that are tool, driver, or other component that
do not adhere to the Kubernetes release cycle.
--- **Kubernetes Core Subprojects**
- *MUST* use the [KEP] process for introducing new features and decision
making.
- *MUST* Adhere to release test health requirements.
- Subprojects must define how releases are performed and milestones are set. Example: **Non Kubernetes Core Subprojects**
- *SHOULD* define how releases are performed.
- *SHOULD* setup and monitor test health.
> - Release milestones Issues impacting multiple subprojects in the SIG should be resolved by the
> - Follows the kubernetes/kubernetes release milestones and schedule SIG's Tech Leads or a federation of Subproject Owners.
> - Priorities for upcoming release are discussed during the SIG meeting following the preceding release and shared through a PR. Priorities are finalized before feature freeze.
> - Code and artifacts are published as part of the kubernetes/kubernetes release
### Technical processes
Subprojects of the SIG *MUST* use the following processes unless explicitly following alternatives ## SIG Retirement
they have defined.
- Proposing and making decisions In the event that the SIG is unable to regularly establish consistent quorum or
- Proposals sent as [KEP] PRs and published to googlegroup as announcement otherwise fulfill its Organizational Management responsibilities
- Follow [KEP] decision making process - after 3 or more months it *SHOULD* be retired
- after 6 or more months it *MUST* be retired
- Test health [Kubernetes]: https://github.com/kubernetes/kubernetes
- Canonical health of code published to [dashboard] [KEPs]: https://github.com/kubernetes/enhancements
- Consistently broken tests automatically send an alert to their google group.
- SIG contributors are responsible for responding to broken tests alert. PRs that break tests should be rolled back if not fixed within 24 hours (business hours).
- Test dashboard checked and reviewed at start of each SIG meeting. Owners assigned for any broken tests and followed up during the next SIG meeting.
Issues impacting multiple subprojects in the SIG should be resolved by either:
- Option 1: SIG Technical Leads
- Option 2: Federation of Subproject Owners
### SIG Retirement
- In the event that the SIG is unable to regularly establish consistent quorum
or otherwise fulfill its Organizational Management responsibilities
- after 3 or more months it *SHOULD* be retired
- after 6 or more months it *MUST* be retired
[k/enhancements]: https://github.com/kubernetes/enhancements
[forums provided]: /communication/README.md [forums provided]: /communication/README.md
[lazy-consensus]: http://en.osswiki.info/concepts/lazy_consensus [lazy-consensus]: http://en.osswiki.info/concepts/lazy_consensus
[super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote [super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote