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.

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.
• Keep up-to-date meeting notes, linked from the SIG's page in the community repo.
• Record meetings and make them publicly available on the Kubernetes Community YouTube playlist.
• Record activity and complete 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 KEPs and other project enhancements.

The process for setting up a SIG or Working Group (WG) is listed in the sig-wg-lifecycle document.

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.

• 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 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.

• 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.

• Lead membership disagreements MAY be escalated to the SIG Chairs. SIG Chair membership disagreements may be escalated to the Steering Committee.

• 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).

• Number: 2+
• Membership tracked in sigs.yaml
• 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 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.
• 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 create the yearly annual report for the group but SHOULD get help with curation from other SIG participants.

• Number: 2+
• Membership tracked in sigs.yaml
• MUST Approve & facilitate the creation of new subprojects
• MUST Approve & facilitate decommissioning of existing subprojects
• MUST Resolve cross-Subproject and cross-SIG technical issues and decisions or delegate to another Lead as needed
• MUST in conjunction with the Chairs identify, track, and maintain the metadata of the SIGs enhancement proposals for the current release and serve as point of contact for the release team, but MAY delegate to other contributors to fulfill these responsibilities
• MUST Review & Approve SIG Enhancement Proposals, but MAY delegate to other contributors to fulfill these responsibilities for individual proposals

Additional information on the Tech Lead role can be found in technical-lead.md; within the Chair & TL Contributor Documentation.

Note: This is a generalized high-level description of the role, and the specifics of the subproject lead role's responsibilities and related processes MUST be defined for individual SIGs or subprojects. The process for becoming an Subproject Lead should be defined in the SIG charter of the SIG owning the subproject.

Subproject Leads are the technical authority for a subproject in the Kubernetes project. They MUST have demonstrated both good judgement and responsibility towards the health of that subproject.

• Number: 2+
• Membership tracked in sigs.yaml via subproject.leads entry and scoped to a subproject
• MUST set technical direction and make or approve design decisions for their subproject - either directly or through delegation
• MUST mentor and guide approvers, reviewers, and contributors to the subproject.
• MUST maintain components, review, shepherd and approve proposals for enhancing areas owned by the subproject
• MUST actively participate in triaging issues and reviewing PRs
• SHOULD be an escalation point for technical discussions and decisions in the subproject
• SHOULD set milestone priorities or delegate this responsibility
• SHOULD ensure a healthy process for discussion and decision making is in place.
• MAY make decisions to resolve conflicts

• Optional if and only if Subproject Leads are defined for the subproject
  • Number: 2+
  • Membership tracked in sigs.yaml via links to OWNERS files
  • If no Subproject Leads are defined for the subproject, the Subproject Owners will be responsible for the same duties.
• Scoped to a subproject defined in sigs.yaml
• MUST actively participate in triaging issues and reviewing PRs
• SHOULD mentor and guide contributors of the subproject
• SHOULD help the subproject leads (if defined) in their responsibilities

• 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)
• MAY build new functionality for subprojects
• MAY participate in decision making for the subprojects they hold roles in
• MUST take an Inclusive Open Source Community Orientation course in support of our community values within 30 days from the date of their appointment.

• 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

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 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 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
• Contributor Comms

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.
• 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 with a lazy consensus period when they are newly created
• MAY Fill in for another named role on a temporary basis

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 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.

Non Kubernetes Core Subprojects

• SHOULD define how releases are performed.
• SHOULD setup and monitor test health.

Issues impacting multiple subprojects in the SIG should be resolved by the SIG's Tech Leads or a federation of Subproject Owners.

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