Skip to content

Commit

Permalink
SIG-Auth governance
Browse files Browse the repository at this point in the history
  • Loading branch information
@tallclair
tallclair committed Apr 4, 2018
1 parent 21a5343 commit f5b6e69
Showing 1 changed file with 101 additions and 73 deletions.
174 changes: 101 additions & 73 deletions sig-auth/governance.md
View file
Original file line number Diff line number Diff line change
@@ -1,44 +1,81 @@
# SIG Governance Template (Short Version)
# SIG Auth Governance

## Roles

Membership for roles tracked in: <link to OWNERS file>
Membership for roles tracked in: [OWNERS]

- Chair
- **Chairs**
- 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 *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.
- Chairs *SHOULD* represent a diverse set of organizations. This is predicated on interest in the
role from multiple organizations with qualified candidates.
- Chairs *MAY* decide to step down at any time 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
- Number: 3
- Defined in [sigs.yaml]


- *Optional Role*: SIG Technical Leads
- **Technical Leads**
- Establish new subprojects
- Decommission existing subprojects
- Resolve X-Subproject technical issues and decisions


- Subproject Owners
- Seed technical leads nominated by legacy SIG leads from subproject owners
- *MUST* ensure that all areas of the SIG (including those that fall outside subprojects) have
active owners.
- *MAY* set SIG milestone priorities.
- *SHOULD* act as an escalation point for technical disputes in subprojects.
- *MUST* resolve issues impacting multiple subprojects in the SIG.
- *SHOULD* meet or communicate regularly enough to ensure they are aligned. Decisions made by
technical leads should be consistent across the SIG. If technical leads are providing
inconsistent direction, then they *MUST* align themselves.
- Technical Leads *MAY* select additional tech leads through a [super-majority] vote amongst tech
leads and chairs. This *SHOULD* be supported by a majority of SIG Members under
[lazy-consensus].
- Technical Leads *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 technical leads to fulfill responsibilities.
- Technical Leads *SHOULD* represent a diverse set of organizations. This is predicated on
interest in the role from multiple organizations with qualified candidates.
- *SHOULD* have a record of consistent solid technical judgement and leadership over a sustained
period especially over areas for which they are the de facto lead
- Number: 3-7
- Defined in [sigs.yaml] and [OWNERS] files



- **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
- Seed subproject owners *MAY* include initial proposal author(s) and/or Tech Leads
- *MUST* be an escalation point for technical decisions and failing or flaky tests in the
subproject
- *MUST* proactively maintain the subproject health and status or delegate this
responsibility. For actively developed projects, this *SHOULD* include setting milestone
priorities, tracking release bits, and ensure adequate test coverage. For maintenance mode
projects, this *SHOULD* include maintaining test health and ensuring compatibility with new
features.
- *MUST* remain active in the role and are automatically removed from the position if they are
unresponsive for > 3 months.
- *SHOULD* have a record of consistent solid technical judgement over a sustained period,
especially over areas for which they are the owner
- *MAY* be removed if not proactively working with other Subproject Owners to fulfill
responsibilities.
- *MAY* decide to step down at any time 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).
- *SHOULD* work to ensure technical excellence within area
- actively work to reduce complexity of the area
- define general acceptance criteria for work as needed (code, test, documentation guidelines,
etc)
- consider cross-project interactions in technical decisions
- prioritize urgent issues appropriately (e.g. addressing critical bugs, security
vulnerabilities, or test failures)
- Number: 1-3 per subproject
- Defined in [sigs.yaml] [OWNERS] files

- Members
Expand All @@ -48,11 +85,15 @@ Membership for roles tracked in: <link to OWNERS file>
(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
- *SHOULD* include all reviewers and approvers in [OWNERS] files for subprojects
- *MUST* remain active in the role and are automatically removed from the position if they are
unresponsive for > 1 year.
- *MAY* be removed if not proactively working with other Subproject Owners to fulfill
responsibilities.

## Organizational management

- SIG meets bi-weekly on zoom with agenda in meeting notes
- 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
Expand All @@ -63,60 +104,47 @@ Membership for roles tracked in: <link to OWNERS file>

#### 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.
- Subprojects *MAY* be created by [KEP] proposal and *MUST* be approved by at least 1 tech lead, 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
- [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with
subproject owners
- Where subprojects processes differ from the SIG, they must document how
- e.g. if subprojects release separately - they must document how release and planning is
performed

### 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
- Proposals *SHOULD* be sent as [KEP] PRs and published to [kubernetes-sig-auth] as an
announcement
- Proposals *MUST* be presented and discussed in at least 1 SIG auth meeting
- If the authors are unable to attend, another community member can be found to champion the
project.
- Proposals *SHOULD* follow [KEP] decision making process
- For proposed extensions to a subproject, the subproject *MUST* be identified in the KEP, and
approvers *MUST* include subproject owners

- 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:
- Canonical health of code published to [testgrid]
- Consistently broken tests automatically send an alert to [kubernetes-sig-auth-test-failures]
- SIG members are responsible for responding to broken tests alert. PRs that break tests should
be rolled back if not fixed within 1 business day.
- 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.

- 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
[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml
[OWNERS]: https://github.com/kubernetes/community/blob/master/sig-auth/OWNERS
[agenda and meeting notes]: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view
[zoom]: https://zoom.us/my/k8s.sig.auth
[testgrid]: https://k8s-testgrid.appspot.com/sig-auth#Summary
[kubernetes-sig-auth]: https://groups.google.com/forum/#!forum/kubernetes-sig-auth
[kubernetes-sig-auth-test-failures]: https://groups.google.com/forum/#!forum/kubernetes-sig-auth-test-failures

0 comments on commit f5b6e69

Please sign in to comment.