Skip to content
This repository has been archived by the owner on Nov 20, 2024. It is now read-only.

Latest commit

 

History

History
63 lines (48 loc) · 3.41 KB

README.md

File metadata and controls

63 lines (48 loc) · 3.41 KB
Raw

SIG Charter Guide

All SIGs must define a charter defining the scope and governance of the SIG.

  • The scope must define what areas the SIG is responsible for directing and maintaining.
  • The governance must outline the responsibilities within the SIG as well as the roles owning those responsibilities.

Steps to create a SIG charter

  1. Copy the template into a new file under sig/sig-YOURSIG/charter.md (sig-architecture example)
  2. Read the Recommendations and requirements so you have context for the template
  3. Fill out the template for your SIG
  4. Update sigs.yaml with the individuals holding the roles as defined in the template.
  5. Add subprojects owned by your SIG in the sigs.yaml
  6. Create a pull request with a draft of your charter.md and sigs.yaml changes. Communicate it within your SIG and get feedback as needed.
  7. Ask for review of your Pull Request by labeling it with committee/steering.
  8. Typically expect feedback within a week of sending your draft.
  9. Once accepted, the steering committee will ratify the PR by merging it.

Steps to update an existing SIG charter

  • For significant changes, or any changes that could impact other SIGs, such as the scope, create a PR and label it form the steering committee for review by adding the committee/steering label.
  • For minor updates to that only impact issues or areas within the scope of the SIG the SIG Chairs should facilitate the change.

SIG Charter approval process

When introducing a SIG charter or modification of a charter the following process should be used. As part of this we will define roles for the OARP process (Owners, Approvers, Reviewers, Participants)

  • Identify a small set of Owners from the SIG to drive the changes. Most typically this will be the SIG chairs.
  • Work with the rest of the SIG in question (Reviewers) to craft the changes. Make sure to keep the SIG in the loop as discussions progress with the Steering Committee (next step). Including the SIG mailing list in communications with the steering committee would work for this.
  • Work with the steering committee (Approvers) to gain approval. This can simply be submitting a PR and labeling it with committee/steering. If more substantial changes are desired it is advisable to socialize those before drafting a PR.
    • The steering committee will be looking to ensure the scope of the SIG as represented in the charter is reasonable (and within the scope of Kubernetes) and that processes are fair.
  • For large changes alert the rest of the community (Participants) as the scope of the changes becomes clear.

If there are questions about this process please reach out to the steering committee.

How to use the templates

SIGs should use the template as a starting point. This document links to the recommended SIG Governance but SIGs may optionally record deviations from these defaults in their charter.

Goals

The primary goal of the charters is to define the scope of the SIG and how the SIG leaders exercise ownership of these areas by taking care of their responsibilities. A majority of the effort should be spent on these concerns.