SIG charter template: Separate SIG and subproject roles #2183
Conversation
By separating the SIG and subproject roles, we can more tightly scope the previous "Membership for roles tracked in: sigs.yaml". The SIG roles are tracked there directly, but subproject roles are incorperated by reference. Now that the subproject roles are in their own subsection, we can spend a bit more time talking about that indirection. I've removed "Seed members established at SIG founding" from the chairs entry, because its already discussed in /committee-steering/governance/README.md (step 4). There's no need to record that procedure in the charter itself, because the initial membership can be recovered from the version controlled history of sigs.yaml. I've split the previous "Members" role into a SIG entry and a subproject entry to clarify that distinction. The previous member line-items are mostly handled in other places now: * "maintain health of at least one subproject or the health of the SIG", "show sustained contributions to at least one subproject or to the SIG", "hold some documented role", and "Includes all reviewers and approvers" are now addressed by the member definitions. * "build new functionality" is not particularly clear, and for most subprojects anyone can contribute issues, pull requests, etc. without being a formal subproject member. * "participate in decision making for the subprojects they hold roles in" is redundant with the other role definitions. I've split the previous "Subproject Owners" into subproject approvers and reviewers. This lets us define subproject members to include both approvers and reviewers while restricting control over some activity (adjusting the OWNERS file) to approvers. The "alter their own OWNERS" wording makes that line generic enough to allow for managing both approvers and reviewers, as well as anything else that the OWNERS file covers. There is no implicit OWNERS nesting, all OWNERS entries must be listed in sigs.yaml. This is a bit more work for sigs.yaml maintainers, but allows for owner/approver calculation without walking all referenced repositories. We also have existing cases where parent and child OWNERS files are in different SIGs/subprojects. For example, kubernetes/kubernetes has /test/e2e/apps/OWNERS in the workloads-api subproject of SIG Apps, while the parent /test/OWNERS is in the testing-commons subproject of SIG Testing. Because of the repo-root restriction, security contacts have an added wrinkle for nested subprojects. The way I've worded it, kubernetes/kubernetes security contact would be a member of all subprojects with an OWNERS file in that repository (assuming the associated SIG had adopted wording like what I'm proposing with this commit). Members don't have many teeth (they mostly SHOULD approve things), and security contacts will have lots of trust, so the broad association here shouldn't cause any problems. I've added a SHOULD for estabilishing security contacts for new repositories. This will probably happen even without the reminder, but it's nice to be explicit. I've also made assorted minor copy-edits near lines I touched.
k8s-ci-robot
added
size/M
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/ok-to-test |
k8s-ci-robot
removed
the
needs-ok-to-test
|
/assign @pwittrock |
|
cc @kubernetes/sig-contributor-experience-pr-reviews |
k8s-ci-robot
added
the
sig/contributor-experience
k8s-ci-robot
added
the
needs-rebase
|
@wking: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
Sorry, I just noticed this PR. We're working on better ways to track ongoing work. Thanks for the suggestions. However: First, the charter template has been heavily refactored in order to attempt to reduce duplication across all SIG charters. Second, references to "subproject owners" referred to a specific role rather than all roles specified by OWNERS files: cc @jdumars |
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
k8s-ci-robot
added
the
lifecycle/stale
|
Previous feedback wasn't addressed and this has been superseded by other changes, so closing. |
By separating the SIG and subproject roles, we can more tightly scope the previous "Membership for roles tracked in:
sigs.yaml". The SIGroles are tracked there directly, but subproject roles are incorperated by reference. Now that the subproject roles are in their own subsection, we can spend a bit more time talking about that indirection.
I've removed "Seed members established at SIG founding" from the chairs entry, because its already discussed in
/committee-steering/governance/README.md(step 4). There's no need to record that procedure in the charter itself, because the initial membership can be recovered from the version controlled history ofsigs.yaml.I've split the previous "Members" role into a SIG entry and a subproject entry to clarify that distinction. The previous member line-items are mostly handled in other places now:
I've split the previous "Subproject Owners" into subproject approvers and reviewers. This lets us define subproject members to include both
approvers and reviewers while restricting control over some activity (adjusting the
OWNERSfile) to approvers. The "alter their ownOWNERS" wording makes that line generic enough to allow for managing both approvers and reviewers, as well as anything else that theOWNERSfile covers.There is no implicit
OWNERSnesting, allOWNERSentries must be listed insigs.yaml. This is a bit more work forsigs.yamlmaintainers, but allows for owner/approver calculation without walking all referenced repositories. We also have existing cases where parent and childOWNERSfiles are in different SIGs/subprojects. For example, kubernetes/kubernetes has/test/e2e/apps/OWNERSin the workloads-apisubproject of SIG Apps, while the parent
/test/OWNERSis in the testing-commons subproject of SIG Testing.Because of the repo-root restriction, security contacts have an added wrinkle for nested subprojects. The way I've worded it, kubernetes/kubernetes security contact would be a member of all subprojects with an
OWNERSfile in that repository (assuming the associated SIG had adopted wording like what I'm proposing with this pull request). Members don't have many teeth (they mostly SHOULD approve things), and security contacts will have lots of trust, so the broad association here shouldn't cause any problems.I've added a SHOULD for estabilishing security contacts for new repositories. This will probably happen even without the reminder, but it's nice to be explicit.
I've also made assorted minor copy-edits near lines I touched.
CC @cblecker, since I'm spinning this off from our discussion here.