Skip to content

Commit 68658bf

Browse files
pwittrockpwittrock
committed
Provide short template for SIG governance
1 parent a182253 commit 68658bf

File tree

2 files changed

+129
-3
lines changed

2 files changed

+129
-3
lines changed

‎committee-steering/governance/README.md

+7-3
Original file line numberDiff line numberDiff line change
@@ -21,8 +21,8 @@ Specific attention has been given to:
2121

2222
## How to use the templates
2323

24-
When developing or modifying a SIG governance doc, the intention is for SIGs to use the templates (*forthcoming*) as
25-
a common set of options SIGs may choose to incorporate into their own governance structure. It is recommended that
24+
When developing or modifying a SIG governance doc, the intention is for SIGs to use the templates (*under development*)
25+
as a common set of options SIGs may choose to incorporate into their own governance structure. It is recommended that
2626
SIGs start by looking at the [Recommendations and requirements] for SIG governance docs and consider what structure
2727
they think will work best for them before pulling items from the templates.
2828

@@ -31,5 +31,9 @@ and project.
3131

3232
- [Recommendations and requirements]
3333

34-
[Recommendations and requirements]: sig-governance-requirements.md
34+
## Templates
35+
36+
- [Short Template]
3537

38+
[Recommendations and requirements]: sig-governance-requirements.md
39+
[Short Template]: sig-governance-template-short.md

‎committee-steering/governance/sig-governance-template-short.md

+122
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,122 @@
1+
# SIG Governance Template (Short Version)
2+
3+
## Roles
4+
5+
Membership for roles tracked in: <link to OWNERS file>
6+
7+
- Chair
8+
- Run operations and processes governing the SIG
9+
- Seed members established at SIG founding
10+
- Chairs *MAY* decide to step down at anytime and propose a replacement. Use lazy consensus amongst
11+
chairs with fallback on majority vote to accept proposal. This *SHOULD* be supported by a majority of
12+
SIG Members.
13+
- Chairs *MAY* select additional chairs through a [super-majority] vote amongst chairs. This
14+
*SHOULD* be supported by a majority of SIG Members.
15+
- Chairs *MUST* remain active in the role and are automatically removed from the position if they are
16+
unresponsive for > 3 months and *MAY* be removed if not proactively working with other chairs to fulfill
17+
responsibilities.
18+
- Number: 2-3
19+
- Defined in [sigs.yaml]
20+
21+
22+
- *Optional Role*: SIG Technical Leads
23+
- Establish new subprojects
24+
- Decommission existing subprojects
25+
- Resolve X-Subproject technical issues and decisions
26+
27+
28+
- Subproject Owners
29+
- Scoped to a subproject defined in [sigs.yaml]
30+
- Seed members established at subproject founding
31+
- *MUST* be an escalation point for technical discussions and decisions in the subproject
32+
- *MUST* set milestone priorities or delegate this responsibility
33+
- *MUST* remain active in the role and are automatically removed from the position if they are unresponsive
34+
for > 3 months.
35+
- *MAY* be removed if not proactively working with other Subproject Owners to fulfill responsibilities.
36+
- *MAY* decide to step down at anytime and propose a replacement. Use [lazy-consensus] amongst subproject owners
37+
with fallback on majority vote to accept proposal. This *SHOULD* be supported by a majority of subproject
38+
contributors (those having some role in the subproject).
39+
- *MAY* select additional subproject owners through a [super-majority] vote amongst subproject owners. This
40+
*SHOULD* be supported by a majority of subproject contributors (through [lazy-consensus] with fallback on voting).
41+
- Number: 3-5
42+
- Defined in [sigs.yaml] [OWNERS] files
43+
44+
- Members
45+
- *MUST* maintain health of at least one subproject or the health of the SIG
46+
- *MUST* show sustained contributions to at least one subproject or to the SIG
47+
- *SHOULD* hold some documented role or responsibility in the SIG and / or at least one subproject
48+
(e.g. reviewer, approver, etc)
49+
- *MAY* build new functionality for subprojects
50+
- *MAY* participate in decision making for the subprojects they hold roles in
51+
- Includes all reviewers and approvers in [OWNERS] files for subprojects
52+
53+
## Organizational management
54+
55+
- SIG meets bi-weekly on zoom with agenda in meeting notes
56+
- *SHOULD* be facilitated by chairs unless delegated to specific Members
57+
- SIG overview and deep-dive sessions organized for Kubecon
58+
- *SHOULD* be organized by chairs unless delegated to specific Members
59+
60+
- Contributing instructions defined in the SIG CONTRIBUTING.md
61+
62+
### Project management
63+
64+
#### Subproject creation
65+
66+
---
67+
68+
Option 1: by SIG Technical Leads
69+
70+
- Subprojects may be created by [KEP] proposal and accepted by [lazy-consensus] with fallback on majority vote of
71+
SIG Technical Leads. The result *SHOULD* be supported by the majority of SIG members.
72+
- KEP *MUST* establish subproject owners
73+
- [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with subproject owners
74+
- Where subprojects processes differ from the SIG governance, they must document how
75+
- e.g. if subprojects release separately - they must document how release and planning is performed
76+
77+
Option 2: by federation of subprojects
78+
79+
- Subprojects may be created by [KEP] proposal and accepted by [lazy-consensus] with fallback on majority vote of
80+
subproject owners in the SIG. The result *SHOULD* be supported by the majority of members.
81+
- KEP *MUST* establish subproject owners
82+
- [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with subproject owners
83+
- Where subprojects processes differ from the SIG governance, they must document how
84+
- e.g. if subprojects release separately - they must document how release and planning is performed
85+
86+
---
87+
88+
- Subprojects must define how releases are performed and milestones are set. Example:
89+
90+
> - Release milestones
91+
> - Follows the kubernetes/kubernetes release milestones and schedule
92+
> - Priorities for upcoming release are discussed during the SIG meeting following the preceding release and
93+
> shared through a PR. Priorities are finalized before feature freeze.
94+
> - Code and artifacts are published as part of the kubernetes/kubernetes release
95+
96+
### Technical processes
97+
98+
Subprojects of the SIG *MUST* use the following processes unless explicitly following alternatives
99+
they have defined.
100+
101+
- Proposing and making decisions
102+
- Proposals sent as [KEP] PRs and published to googlegroup as announcement
103+
- Follow [KEP] decision making process
104+
105+
- Test health
106+
- Canonical health of code published to <link to dashboard>
107+
- Consistently broken tests automatically send an alert to <link to google group>
108+
- SIG members are responsible for responding to broken tests alert. PRs that break tests should be rolled back
109+
if not fixed within 24 hours (business hours).
110+
- Test dashboard checked and reviewed at start of each SIG meeting. Owners assigned for any broken tests.
111+
and followed up during the next SIG meeting.
112+
113+
Issues impacting multiple subprojects in the SIG should be resolved by either:
114+
115+
- Option 1: SIG Technical Leads
116+
- Option 2: Federation of Subproject Owners
117+
118+
[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus
119+
[super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote
120+
[KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md
121+
[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454
122+
[OWNERS]: contributors/devel/owners.md

0 commit comments

Comments
 (0)