From 32d184cee2ecb7c72f9de75e687f4a88f7c36413 Mon Sep 17 00:00:00 2001 From: Phillip Wittrock Date: Mon, 9 Jul 2018 10:46:24 -0700 Subject: Change SIG Charter to reference base governance instead of copy-pasting it --- committee-steering/governance/README.md | 2 +- .../governance/sig-charter-template.md | 65 +++++++++ .../governance/sig-governance-template-short.md | 147 ------------------- committee-steering/governance/sig-governance.md | 159 +++++++++++++++++++++ governance.md | 2 +- 5 files changed, 226 insertions(+), 149 deletions(-) create mode 100644 committee-steering/governance/sig-charter-template.md delete mode 100644 committee-steering/governance/sig-governance-template-short.md create mode 100644 committee-steering/governance/sig-governance.md diff --git a/committee-steering/governance/README.md b/committee-steering/governance/README.md index 7321c055..92cca399 100644 --- a/committee-steering/governance/README.md +++ b/committee-steering/governance/README.md @@ -69,7 +69,7 @@ Specific attention has been given to: See [frequently asked questions] [Recommendations and requirements]: sig-governance-requirements.md -[Short Template]: sig-governance-template-short.md +[Short Template]: sig-charter-template.md [frequently asked questions]: FAQ.md [sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml [sig-architecture example]: ../../sig-architecture/charter.md diff --git a/committee-steering/governance/sig-charter-template.md b/committee-steering/governance/sig-charter-template.md new file mode 100644 index 00000000..d8e03550 --- /dev/null +++ b/committee-steering/governance/sig-charter-template.md @@ -0,0 +1,65 @@ +# SIG YOURSIG Charter + +This charter adheres to the conventions described in the [Kubernetes Charter README]. + +## Scope + +Include a 2-3 sentence summary of what work SIG TODO does. Imagine trying to +explain your work to a colleague who is familiar with Kubernetes but not +necessarily all of the internals. + +### In scope + +Link to SIG section in [sigs.yaml] + +#### Code, Binaries and Services + +- list of what qualifies a piece of code, binary or service +- as falling into the scope of this SIG +- e.g. *clis for working with Kubernetes APIs*, +- *CI for kubernetes repos*, etc +- **This is NOT** a list of specific code locations, +- or projects those go in [sigs.yaml] + +#### Cross-cutting and Externally Facing Processes + +- list of the non-internal processes +- that are owned by this SIG +- e.g. qualifying and cutting a Kubernetes release, +- organizing mentorship programs, etc + +### Out of scope + +Outline of things that could be confused as falling into this SIG but don't or don't right now. + +## Roles and Organization Management + +This sig follows adheres to the Roles and Organization Management outline in [sig-governance] +and opts-in to updates and modifications to [sig-governance]. + +### Additional responsibilities of Chairs + +- list of any additional responsibilities +- of Chairs + +### Additional responsibilities of Tech Leads + +- list of any additional responsibilities +- of Tech Leads + +### Deviations from [sig-governance] + +- list of other ways this SIG's roles and governance differ from +- the outline +- **If the SIG doesn't have either Chairs or Tech Leads specify that here.** + +### Subproject Creation + +Pick one: + +1. SIG Technical Leads +2. Federation of Subprojects + +[sig-governance]: sig-governance.md +[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454 +[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md diff --git a/committee-steering/governance/sig-governance-template-short.md b/committee-steering/governance/sig-governance-template-short.md deleted file mode 100644 index 2ac5451a..00000000 --- a/committee-steering/governance/sig-governance-template-short.md +++ /dev/null @@ -1,147 +0,0 @@ -# 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. Removal of a chair can be done either through a voluntary step down as outlined - above OR by a consensus of other chairs and SIG subproject owners. - - 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 - -- Security Contact - - *MUST* be a contact point for the Product Security Team to reach out to for - triaging and handling of incoming issues - - *MUST* accept the [Embargo Policy](https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#embargo-policy) - - Defined in `SECURITY_CONTACTS` files, this is only relevant to the root file in - the repository, there is a template - [here](https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS) - -## 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 - -[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus -[super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote -[KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md -[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454 -[OWNERS]: contributors/devel/owners.md -[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md diff --git a/committee-steering/governance/sig-governance.md b/committee-steering/governance/sig-governance.md new file mode 100644 index 00000000..a2ceb7c8 --- /dev/null +++ b/committee-steering/governance/sig-governance.md @@ -0,0 +1,159 @@ +# SIG Roles and Organizational Governance + +This charter adheres to the conventions described in the [Kubernetes Charter README]. + +This document will be updated as needed to meet the current needs of the Kubernetes project. + +## Roles + +### Notes on Roles + +Unless otherwise stated, individuals are expected to be responsive and active within +their roles. Within this section member refers to a member of a Chair, Tech Lead or +Subproject Owner Role, **not** a SIG or Organization member. + +- Initial members are defined at the founding of the SIG or Subproject as part of the acceptance + of that SIG or Subproject. +- Members *SHOULD* be active and responsive in their Roles. +- Members taking an extended leave of 1 or more months *SHOULD* + coordinate with other members sharing the Role to ensure the + role is adequately staffed during the leave. +- Members going on leave for 1-3 months *MAY* work with other + members to identify a temporary replacement if need be. +- Members of a role *SHOULD* remove any other members 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 members, or if there are not + enough *active* members to get a super-majority of votes cast, then removal may occur + through a [super-majority] vote between Chairs, Tech Leads and Subproject Owners +- Membership disagreements may be escalated to the SIG Chairs. SIG Chair membership + disagreements may be escalated to the Steering Committee. + +- Members *MAY* decide to step down at anytime and propose a replacement. Use lazy consensus amongst + other members with fallback on majority vote to accept proposal. The candidate *SHOULD* be supported by a a + majority of SIG Members or Subproject Contributors (as applicable). +- Members *MAY* select additional members through a [super-majority] vote amongst members. This + *SHOULD* be supported by a majority of SIG Members or Subproject Contributors (as applicable). + + +### Chair + +- Chair + - Run operations and processes governing the SIG + - Number: 2-3 + - Membership tracked in [sigs.yaml] + +### Tech Lead + +- *Optional Role*: SIG Technical Leads + - Establish new subprojects + - Decommission existing subprojects + - Resolve X-Subproject technical issues and decisions + - Number: 2-3 + - Membership tracked in [sigs.yaml] + +### Subproject Owner + +- Subproject Owners + - Scoped to a subproject defined in [sigs.yaml] + - Seed members 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] + +### Member + +- Members + - *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* 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 + +### Security Contact + +- Security Contact + - *MUST* be a contact point for the Product Security Team 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] + +## 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 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: + +> - 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 + +[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus +[super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote +[KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md +[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454 +[OWNERS]: contributors/devel/owners.md +[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md +[Embargo Policy]: https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#embargo-policy +[SECURITY_CONTACTS]: https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS diff --git a/governance.md b/governance.md index 541de03e..bc12c8eb 100644 --- a/governance.md +++ b/governance.md @@ -173,6 +173,6 @@ All contributors must sign the CNCF CLA, as described [here](CLA.md). [community membership]: /community-membership.md [sig governance]: /sig-governance.md [owners]: community-membership.md#subproject-owner -[short template]: committee-steering/governance/sig-governance-template-short.md +[short template]: committee-steering/governance/sig-charter-template.md [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]() -- cgit v1.2.3