Provide short template for SIG governance
This commit is contained in:
Phillip Wittrock
parent
a18225305f
commit
68658bff6e
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
Loading…
Reference in New Issue