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

SIG governance: clean up formatting & wording 

no-op on responsibilities, just formatting and phrasing improvements.
This commit is contained in:
Bob Killen 2023-03-22 18:24:31 -05:00
parent ad1bca2354
commit bd5c10e8b5
1 changed files with 166 additions and 146 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,35 +1,34 @@
# SIG Roles and Organizational Governance
This charter adheres to the conventions described in the [Kubernetes Charter README].
It will be updated as needed to meet the current needs of the Kubernetes project.
This charter adheres to the conventions described in the
[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
transparency, and route contributors to the appropriate SIG, SIGs should follow
these guidelines:
- Have an approved Charter [SIG charter process]
To standardize Special Interest Group efforts, create maximum transparency, and
route contributors to the appropriate SIG; SIGs should follow these guidelines:
- Have an approved Charter [SIG charter process].
- 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
repo
repo.
- 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
least once a year.
- This is separate from the [annual report].
- Participate in release planning meetings and retrospectives, and burndown
meetings, as needed
- Ensure related work happens in a project-owned github org and repository, with
code and tests explicitly owned and supported by the SIG, including issue
triage, PR reviews, test-failure response, bug fixes, etc.
- Use the [forums provided] as the primary means of working, communicating, and
collaborating, as opposed to private emails and meetings
least once a year.
- This is separate from the [annual report].
- Participate in release planning meetings, retrospectives, and burndown
meetings, as needed.
- Ensure related work happens in a project-owned GitHub org and repository,
with code and tests explicitly owned and supported by the SIG, including
issue triage, PR reviews, test-failure response, bug fixes, etc.
- 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
folder located in the Kubernetes/community repo if the groups contributor steps
and experience are different or more in-depth than the documentation listed in
the general [contributor guide] and [devel] folder.
- 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]
folder located in the Kubernetes/community repo if the groups contributor
steps and experience are different or more in-depth than the documentation
listed in the general [contributor guide] and [devel] folder.
- Help and sponsor working groups that the SIG is interested in investing in
- Track and identify all [KEPs] and other project enhancements.
The process for setting up a SIG or Working Group (WG) is listed in the
[sig-wg-lifecycle] document.
@ -38,83 +37,90 @@ The process for setting up a SIG or Working Group (WG) is listed in the
### Notes on Roles
Within this section "Lead" refers to someone who is a member of the union
of a Chair, Tech Lead, or Subproject Owner role. Leads may, and frequently do
hold more than one role. There is no one lead to any Kubernetes community
group. Leads have specific decision making power over some part of a group
and thus additional accountability. Each role is detailed below.
Within this section, "Lead" refers to someone who is a member of the union of a
Chair, Tech Lead, or Subproject Owner role. Leads may, and frequently do, hold
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 and
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.
#### Activity Expectations
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
- 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 going on leave for 1-3 months *MAY* work with other Leads to identify a temporary replacement.
- 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.
- 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.
- Leads taking an extended leave of 1 or more months *SHOULD* coordinate with
other leads to ensure the role is adequately staffed during their leave.
- Leads going on leave for 1-3 months *MAY* work with other Leads to identify a
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
- Leads *MUST* be at least a ["member" on our contributor ladder] to
be eligible to hold a leadership role within a SIG.
- SIGs *MAY* prefer various levels of domain knowledge depending on the
role. This should be documented.
- People management interests - there's a lot of us!
- Leads *MUST* be at least a ["member" on our contributor ladder] to be
eligible to hold a leadership role within a SIG.
- SIGs *MAY* prefer various levels of domain knowledge depending on the role.
This should be documented.
- Interest or skills in people management.
#### Escalations
- 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
- 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
proposal. The candidate *SHOULD* be supported by a majority of SIG contributors
or the Subproject contributors (as applicable).
- Leads *MAY* select additional leads through a [super-majority] vote
amongst leads. This *SHOULD* be supported by a majority of SIG contributors or
Subproject contributors (as applicable).
- Leads *MAY* decide to step down at anytime and propose a replacement. Use
lazy consensus amongst the other Leads with fallback on majority vote to
accept the proposal. The candidate *SHOULD* be supported by a majority of
SIG contributors or Subproject contributors (as applicable).
- Leads *MAY* select additional leads through a [super-majority] vote amongst
leads. This *SHOULD* be supported by a majority of SIG contributors or
Subproject contributors (as applicable).
### Chair
#### Chair
- Number: 2+
- Membership tracked in [sigs.yaml]
In addition, run operations and processes governing the SIG:
- *SHOULD* define how priorities and commitments are managed and delegate to other leads as needed
- *SHOULD* drive charter changes (including creation) to get community buy-in but *MAY* delegate content creation to SIG contributors
- *SHOULD* define how priorities and commitments are managed. *MAY* delegate to
other leads as needed.
- *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
metadata of the SIGs enhancements for the current release and serve as
point of contact for the release team, but *MAY* delegate to other
contributors to fulfill these responsibilities
- *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
including subprojects and their meeting information but *SHOULD* delegate the
need for subproject meetings to subproject owners
- *SHOULD* facilitate meetings but *MAY* delegate to other Leads or future
chairs/chairs in training
- *MUST* ensure there is a maintained CONTRIBUTING.md document in the
contributors to fulfill these responsibilities.
- *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,
including subprojects and their meeting information, but *SHOULD* delegate
the need for subproject meetings to subproject owners.
- *SHOULD* facilitate meetings but *MAY* delegate to other Leads or future
chairs/chairs in training.
- *MUST* ensure there is a maintained CONTRIBUTING.md document in the
appropriate SIG folder if the contributor experience or on-boarding knowledge
is different than in the general [contributor guide]. *MAY* delegate to
contributors to create or update.
- *MUST* organize KubeCon/CloudNativeCon Intros and Deep Dives with CNCF Event
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* coordinate sponsored working group updates to the SIG and the wider
community
- *MUST* organize KubeCon/CloudNativeCon Intros and Deep Dives with CNCF Event
staff and approve presented content but *MAY* delegate to other contributors.
- *MUST* ensure meetings are recorded and made available.
- *MUST* coordinate sponsored working group updates to the SIG and the wider
community.
- *MUST* coordinate communication and be a connector with other community
groups like SIGs and the Steering Committee but *MAY* delegate the actual
communication and creation of content to other contributors where
appropriate
- *MUST* present yearly [annual report] for the group but *SHOULD* get help with
curation from other SIG participants
groups like SIGs and the Steering Committee but *MAY* delegate the actual
communication and creation of content to other contributors where appropriate.
- *MUST* create the yearly [annual report] for the group but *SHOULD* get help
with curation from other SIG participants.
### Tech Lead
#### Tech Lead
- Number: 2+
- Membership tracked in [sigs.yaml]
@ -132,44 +138,42 @@ curation from other SIG participants
Additional information on the Tech Lead role can be found in
[technical-lead.md]; within the [Chair & TL Contributor Documentation].
### Subproject Owner
#### Subproject Owner
- Subproject Owners
- Scoped to a subproject defined in [sigs.yaml]
- Seed leads and contributors established at subproject founding
- *SHOULD* be an escalation point for technical discussions and decisions in
- Number: 2-3
- Scoped to a subproject defined in [sigs.yaml]
- Seed leads and contributors established at subproject founding
- *SHOULD* be an escalation point for technical discussions and decisions in
the subproject
- *SHOULD* set milestone priorities or delegate this responsibility
- Number: 2-3
- Membership tracked in [sigs.yaml]
- *SHOULD* set milestone priorities or delegate this responsibility
- Membership tracked in [sigs.yaml] via links to OWNERS files
### All Leads
#### All Leads
- *SHOULD* maintain health of at least one subproject or the health of the SIG
- *SHOULD* show sustained contributions to at least one subproject or to the
SIG
- *SHOULD* maintain health of their SIG or subproject
- *SHOULD* show sustained contributions to at least one subproject or the the
SIG at large.
- *SHOULD* hold some documented role or responsibility in the SIG and / or at
least one subproject
(e.g. reviewer, approver, etc)
least one subproject (e.g. reviewer, approver, etc)
- *MAY* build new functionality for subprojects
- *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 support of our community values
within 30 days from the date of their appointment.
- *MUST* take an [Inclusive Open Source Community Orientation course] in
support of our community values within 30 days from the date of their
appointment.
### Security Contact
- Security Contact
- *MUST* be a contact point for the Product Security Committee to reach out to
for triaging and handling of incoming issues
- *MUST* accept the [Embargo Policy]
- Defined in `SECURITY_CONTACTS` files, this is only relevant to the root file
in the repository. Template [SECURITY_CONTACTS]
- Defined in `SECURITY_CONTACTS` at the root of the repository. Example:
[SECURITY_CONTACTS]
- *MUST* be a contact point for the Security Response Committee to reach out to
for triaging and handling of incoming issues
- *MUST* accept the [Embargo Policy]
### Other Roles
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
governance requirements, including defining more roles to sustain the group. If
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
a SIG needs to change the Chair and Tech Lead position to include or remove
duties, this needs to be approved by the Steering Committee. Newly created roles
that don't assume any responsibility of Chair and/or Tech Lead should follow
@ -177,59 +181,73 @@ the governing processes in the SIGs charter.
Example of SIG roles created to help operations:
- [The Release Team: Bug Triage, CI Signal, and more]
- [API Reviewer and Moderator]
- [Production Readiness Reviewer]
- [Events Lead]
- [PR Wrangler]
- [The Release Team: Bug Triage, CI Signal, and more]
- [API Reviewer and Moderator]
- [Production Readiness Reviewer]
- [Events Lead]
- [PR Wrangler]
- [Marketing Council]
Other roles...
- *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
duties from Chairs and/or Tech Leads on a non-temporary basis
- *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 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
sig-governance.md listed role
- *SHOULD* be sent to dev@kubernetes.io for awareness as a notice
and a lazy consensus period when they are newly created
- *MAY* Fill in for another named role on a temporary basis
#### Subproject Creation
sig-governance.md listed role.
- *SHOULD* be sent to dev@kubernetes.io for awareness as a notice with a lazy
consensus period when they are newly created
- *MAY* Fill in for another named role on a temporary basis
---
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
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
### Subproject Creation
Option 2: by Federation of Subprojects
#### Option 1: by SIG Technical Leads
- Subprojects may be created by [KEP] proposal and accepted by [lazy-consensus] with fallback on majority vote of
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 be created by [KEP] proposal and accepted by [lazy-consensus]
with fallback on majority vote of 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
Subprojects may create repos under *github.com/kubernetes-sigs* through [lazy-consensus] of subproject owners.
#### Option 2: by Federation of Subprojects
---
Subprojects may create repos under *github.com/kubernetes-sigs* through
[lazy-consensus] of subproject owners.
- Subprojects must define how releases are performed and milestones are set. Example:
Subprojects may be created by [KEP] proposal and accepted by [lazy-consensus]
with fallback on majority vote of 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
### Subproject Release Process Requirements
- Subprojects must define how releases are performed and milestones are set.
**Example:**
> - Release milestones
> - Follows the kubernetes/kubernetes release milestones and schedule
> - 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.
> - 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
they have defined.
### Subproject Technical processes
Subprojects of the SIG *MUST* use the following processes unless explicitly
following alternatives they have defined.
- Proposing and making decisions
- Proposals sent as [KEP] PRs and published to googlegroup as announcement
@ -238,22 +256,24 @@ they have defined.
- Test health
- Canonical health of code published to [dashboard]
- 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.
- 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:
Issues impacting multiple subprojects in the SIG should be resolved by the
SIG's Tech Leads or a federation of Subproject Owners.
- Option 1: SIG Technical Leads
- Option 2: Federation of Subproject Owners
### SIG Retirement
## 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
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
[KEPs]: https://github.com/kubernetes/enhancements
[forums provided]: /communication/README.md
[lazy-consensus]: http://en.osswiki.info/concepts/lazy_consensus
[super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote