Merge pull request #7454 from palnabarun/subproject-leads
governance: add Subproject Leads as a named role in the SIG governance
This commit is contained in:
commit
ce04e02575
|
@ -136,15 +136,40 @@ the acceptance of that SIG or Subproject.
|
|||
Additional information on the Tech Lead role can be found in
|
||||
[technical-lead.md]; within the [Chair & TL Contributor Documentation].
|
||||
|
||||
#### Subproject Owner
|
||||
#### Subproject Lead
|
||||
|
||||
**Note:** This is a generalized high-level description of the role, and the
|
||||
specifics of the subproject lead role's responsibilities and related
|
||||
processes *MUST* be defined for individual SIGs or subprojects. The process
|
||||
for becoming an Subproject Lead should be defined in the SIG charter of the
|
||||
SIG owning the subproject.
|
||||
|
||||
Subproject Leads are the technical authority for a subproject in the Kubernetes
|
||||
project. They *MUST* have demonstrated both good judgement and responsibility
|
||||
towards the health of that subproject.
|
||||
|
||||
- Number: 2+
|
||||
- Scoped to a subproject defined in [sigs.yaml]
|
||||
- Seed leads and contributors established at subproject founding
|
||||
- *SHOULD* be an escalation point for technical discussions and decisions in
|
||||
the subproject
|
||||
- Membership tracked in [sigs.yaml] via *subproject.leads* entry and scoped to a subproject
|
||||
- *MUST* set technical direction and make or approve design decisions for their subproject - either directly or through delegation
|
||||
- *MUST* mentor and guide approvers, reviewers, and contributors to the subproject.
|
||||
- *MUST* maintain components, review, shepherd and approve proposals for enhancing areas owned by the subproject
|
||||
- *MUST* actively participate in triaging issues and reviewing PRs
|
||||
- *SHOULD* be an escalation point for technical discussions and decisions in the subproject
|
||||
- *SHOULD* set milestone priorities or delegate this responsibility
|
||||
- Membership tracked in [sigs.yaml] via links to OWNERS files
|
||||
- *SHOULD* ensure a healthy process for discussion and decision making is in place.
|
||||
- *MAY* make decisions to resolve conflicts
|
||||
|
||||
#### Subproject Owner
|
||||
|
||||
- *Optional if and only if Subproject Leads are defined for the subproject*
|
||||
- Number: 2+
|
||||
- Membership tracked in [sigs.yaml] via links to OWNERS files
|
||||
- *If no Subproject Leads are defined for the subproject, the Subproject Owners will be responsible for the same duties.*
|
||||
- Scoped to a subproject defined in [sigs.yaml]
|
||||
- *MUST* actively participate in triaging issues and reviewing PRs
|
||||
- *SHOULD* mentor and guide contributors of the subproject
|
||||
- *SHOULD* help the subproject leads (if defined) in their responsibilities
|
||||
|
||||
|
||||
#### All Leads
|
||||
|
||||
|
|
|
@ -183,50 +183,17 @@ in an [OWNERS] file (for repos using the bot).
|
|||
- Mentor contributors and reviewers
|
||||
- May approve code contributions for acceptance
|
||||
|
||||
## Subproject Owner
|
||||
|
||||
**Note:** This is a generalized high-level description of the role, and the
|
||||
specifics of the subproject owner role's responsibilities and related
|
||||
processes *MUST* be defined for individual SIGs or subprojects.
|
||||
|
||||
Subproject Owners are the technical authority for a subproject in the Kubernetes
|
||||
project. They *MUST* have demonstrated both good judgement and responsibility
|
||||
towards the health of that subproject. Subproject Owners *MUST* set technical
|
||||
direction and make or approve design decisions for their subproject - either
|
||||
directly or through delegation of these responsibilities.
|
||||
## Subproject Lead
|
||||
|
||||
**Defined by:** *owners* entry in subproject [OWNERS] files as defined by [sigs.yaml] *subproject.owners*
|
||||
|
||||
### Requirements
|
||||
The [SIG Governance][sig-governance-subproject-lead] mentions in details the responsibilities of a Subproject Lead.
|
||||
|
||||
The process for becoming an subproject Owner should be defined in the SIG
|
||||
charter of the SIG owning the subproject. Unlike the roles outlined above, the
|
||||
Owners of a subproject are typically limited to a relatively small group of
|
||||
decision makers and updated as fits the needs of the subproject.
|
||||
## Subproject Owner
|
||||
|
||||
The following apply to the subproject for which one would be an owner.
|
||||
**Defined by:** *owners* entry in subproject [OWNERS] files as defined by [sigs.yaml] *subproject.owners*
|
||||
|
||||
- Deep understanding of the technical goals and direction of the subproject
|
||||
- Deep understanding of the technical domain of the subproject
|
||||
- Sustained contributions to design and direction by doing all of:
|
||||
- Authoring and reviewing proposals
|
||||
- Initiating, contributing and resolving discussions (emails, GitHub issues, meetings)
|
||||
- Identifying subtle or complex issues in designs and implementation PRs
|
||||
- Directly contributed to the subproject through implementation and / or review
|
||||
|
||||
### Responsibilities and privileges
|
||||
|
||||
The following apply to the subproject for which one would be an owner.
|
||||
|
||||
- Make and approve technical design decisions for the subproject.
|
||||
- Set technical direction and priorities for the subproject.
|
||||
- Define milestones and releases.
|
||||
- Mentor and guide approvers, reviewers, and contributors to the subproject.
|
||||
- Ensure continued health of subproject
|
||||
- Adequate test coverage to confidently release
|
||||
- Tests are passing reliably (i.e. not flaky) and are fixed when they fail
|
||||
- Ensure a healthy process for discussion and decision making is in place.
|
||||
- Work with other subproject owners to maintain the project's overall health and success holistically
|
||||
The [SIG Governance][sig-governance-subproject-owner] mentions in details the responsibilities of a Subproject Owner.
|
||||
|
||||
## Inactive members
|
||||
|
||||
|
@ -281,3 +248,5 @@ before being able to contribute effectively.
|
|||
[elevated set of permissions]: #Responsibilities-and-privileges
|
||||
[Devstats project]: https://k8s.devstats.cncf.io/
|
||||
[continuously active]: #inactive-members
|
||||
[sig-governance-subproject-lead]: /committee-steering/sig-governance.md#subproject-lead
|
||||
[sig-governance-subproject-owner]: /committee-steering/sig-governance.md#subproject-owner
|
||||
|
|
|
@ -230,6 +230,7 @@ type Subproject struct {
|
|||
Description string `yaml:",omitempty"`
|
||||
Contact *Contact `yaml:",omitempty"`
|
||||
Owners []string
|
||||
Leads []Person `yaml:",omitempty"`
|
||||
Meetings []Meeting `yaml:",omitempty"`
|
||||
}
|
||||
|
||||
|
@ -395,6 +396,9 @@ func (c *Context) Sort() {
|
|||
return subproject.Contact.GithubTeams[i].Name < subproject.Contact.GithubTeams[j].Name
|
||||
})
|
||||
}
|
||||
sort.Slice(subproject.Leads, func(i, j int) bool {
|
||||
return subproject.Leads[i].GitHub < subproject.Leads[j].GitHub
|
||||
})
|
||||
sort.Strings(subproject.Owners)
|
||||
sort.Slice(subproject.Meetings, func(i, j int) bool {
|
||||
return subproject.Meetings[i].Description < subproject.Meetings[j].Description
|
||||
|
|
|
@ -89,6 +89,12 @@ The following [subprojects][subproject-definition] are owned by sig-{{.Label}}:
|
|||
### {{.Name}}
|
||||
{{- if .Description }}
|
||||
{{ trimSpace .Description }}
|
||||
{{- end }}
|
||||
{{- if .Leads }}
|
||||
- **Leads:**{{ range .Leads }}
|
||||
- {{.Name}} (**[@{{.GitHub}}](https://github.com/{{.GitHub}})**){{if .Company}}, {{.Company}}{{end}}
|
||||
{{- end }}
|
||||
|
||||
{{- end }}
|
||||
- **Owners:**
|
||||
{{- range .Owners }}
|
||||
|
|
Loading…
Reference in New Issue