Skip to content

Latest commit

 

History

History
138 lines (103 loc) · 6.37 KB

sig-governance-template-short.md

File metadata and controls

138 lines (103 loc) · 6.37 KB
Raw

SIG YOURSIG Charter

This charter adheres to the conventions described in the Kubernetes Charter README.

Scope

This section defines the scope of things that would fall under ownership by this SIG. It must be used when determining whether subprojects should fall into this SIG.

In scope

Outline of what falls into the scope of this SIG

Out of scope

Outline of things that could be confused as falling into this SIG but don't

Roles

Membership for roles tracked in: sigs.yaml

  • Chair

    • Run operations and processes governing the SIG
    • Seed members established at SIG founding
    • Chairs MAY decide to step down at anytime and propose a replacement. Use lazy consensus amongst chairs with fallback on majority vote to accept proposal. This SHOULD be supported by a majority of SIG Members.
    • Chairs MAY select additional chairs through a super-majority vote amongst chairs. This SHOULD be supported by a majority of SIG Members.
    • Chairs MUST remain active in the role and are automatically removed from the position if they are unresponsive for > 3 months and MAY be removed if not proactively working with other chairs to fulfill responsibilities.
    • Number: 2-3
    • Defined in sigs.yaml

  • Optional Role: SIG Technical Leads

    • Establish new subprojects
    • Decommission existing subprojects
    • Resolve X-Subproject technical issues and decisions

  • Subproject Owners

    • Scoped to a subproject defined in sigs.yaml
    • Seed members established at subproject founding
    • MUST be an escalation point for technical discussions and decisions in the subproject
    • MUST set milestone priorities or delegate this responsibility
    • MUST remain active in the role and are automatically removed from the position if they are unresponsive for > 3 months.
    • MAY be removed if not proactively working with other Subproject Owners to fulfill responsibilities.
    • MAY decide to step down at anytime and propose a replacement. Use lazy-consensus amongst subproject owners with fallback on majority vote to accept proposal. This SHOULD be supported by a majority of subproject contributors (those having some role in the subproject).
    • MAY select additional subproject owners through a super-majority vote amongst subproject owners. This SHOULD be supported by a majority of subproject contributors (through lazy-consensus with fallback on voting).
    • Number: 3-5
    • Defined in OWNERS files that are specified in sigs.yaml

  • Members

    • MUST maintain health of at least one subproject or the health of the SIG
    • MUST show sustained contributions to at least one subproject or to the SIG
    • 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
    • Includes all reviewers and approvers in OWNERS files for subprojects

Organizational management

  • SIG meets bi-weekly on zoom with agenda in meeting notes

    • SHOULD be facilitated by chairs unless delegated to specific Members

  • SIG overview and deep-dive sessions organized for Kubecon

    • SHOULD be organized by chairs unless delegated to specific Members

  • Contributing instructions defined in the SIG CONTRIBUTING.md

Project management

Subproject creation

Option 1: by SIG Technical Leads

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

  • Proposing and making decisions

    • Proposals sent as KEP PRs and published to googlegroup as announcement
    • Follow KEP decision making process

  • Test health

    • Canonical health of code published to
    • Consistently broken tests automatically send an alert to
    • SIG members 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