diff options
| -rw-r--r-- | committee-steering/governance/README.md | 10 | ||||
| -rw-r--r-- | committee-steering/governance/sig-governance-template-short.md | 122 |
2 files changed, 129 insertions, 3 deletions
diff --git a/committee-steering/governance/README.md b/committee-steering/governance/README.md index c6fcdad0..4eb5e1ad 100644 --- a/committee-steering/governance/README.md +++ b/committee-steering/governance/README.md @@ -21,8 +21,8 @@ Specific attention has been given to: ## How to use the templates -When developing or modifying a SIG governance doc, the intention is for SIGs to use the templates (*forthcoming*) as -a common set of options SIGs may choose to incorporate into their own governance structure. It is recommended that +When developing or modifying a SIG governance doc, the intention is for SIGs to use the templates (*under development*) +as a common set of options SIGs may choose to incorporate into their own governance structure. It is recommended that SIGs start by looking at the [Recommendations and requirements] for SIG governance docs and consider what structure they think will work best for them before pulling items from the templates. @@ -31,5 +31,9 @@ and project. - [Recommendations and requirements] -[Recommendations and requirements]: sig-governance-requirements.md +## Templates + +- [Short Template] +[Recommendations and requirements]: sig-governance-requirements.md +[Short Template]: sig-governance-template-short.md diff --git a/committee-steering/governance/sig-governance-template-short.md b/committee-steering/governance/sig-governance-template-short.md new file mode 100644 index 00000000..98aed04d --- /dev/null +++ b/committee-steering/governance/sig-governance-template-short.md @@ -0,0 +1,122 @@ +# SIG Governance Template (Short Version) + +## Roles + +Membership for roles tracked in: <link to OWNERS file> + +- 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 [sigs.yaml] [OWNERS] files + +- 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 <link to dashboard> + - Consistently broken tests automatically send an alert to <link to google group> + - 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 |