WIP: add guiding policy for contribex review on test-infra repo #7931
Conversation
k8s-ci-robot
added
the
do-not-merge/work-in-progress
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Priyankasaggu11929 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 |
k8s-ci-robot
added
the
approved
|
/hold for reviews |
k8s-ci-robot
added
the
do-not-merge/hold
Priyankasaggu11929
force-pushed
the
contribex-owners-policy
branch
2 times, most recently
from
cd93bb5
to
4b8e757
Compare
Priyankasaggu11929
force-pushed
the
contribex-owners-policy
branch
from
4b8e757
to
87cf722
Compare
There was a problem hiding this comment.
Thanks for starting this @Priyankasaggu11929 ❤️
Leaving a few initial comments!
| A review from SIG Contributor Experience is necessary if any changes introduced by a pull request to the test-infra repo: | ||
|
|
||
| - Introduce changes to how humans interact with Prow and its components (changes that alter contributor user experience) | ||
| - Introduce changes to how bot interact with Prow? (TODO: verify!) |
There was a problem hiding this comment.
Hmm, I'm not sure if this falls under the purview of ContribEx. It would help to narrow the scope down to aspects that end up being surfaced to contributors themselves. For example:
- If there is a change in how the bot handles webhooks, that's probably better handled by SIG Testing considering they own that code and have expertise in it.
- If there is a change that introduces retries, but as a side result of that, the bot ends up commenting more or less than it did before, then that is something that we should be chiming in on.
There was a problem hiding this comment.
If there is a change that introduces retries, but as a side result of that, the bot ends up commenting more or less than it did before, then that is something that we should be chiming in on.
Presumably a change like this would only introduce more bot comments if there is a bug, so this change wouldn't need review either.
I would expect under the current unwritten policy that a change like "prow now automatically closes PRs without CLA after 5 days" to require contribex review of the proposed workflow and any technical details to remain under whatever project implements it (so probably prow/plugins technical owners), while "prow now handles transient github failures better" to remain SIG Testing / Prow owners.
|
|
||
| #### Plugins under ContribEx Review | ||
|
|
||
| Following plugins fall under ContribEx review: |
There was a problem hiding this comment.
If we are scoping plugins under ContribEx's purview, we should probably also include the easter-eggy plugins here as well like:
- shrug
- joke
- cat
- dog
- pony
- shrug
- heart
Mainly because some of these pick images/content randomly from a pre-existing set and we want to make sure that set deosn't change, and if it does, it is an acceptable change.
There's also plugins like sigmention and WIP that are contributor facing.
There was a problem hiding this comment.
I don't think trying to enumerate the plugins makes sense.
Any plugin can introduce contributor facing behavior changes, and making changes to any of these plugins can not involve a contributor workflow change (e.g. a simple bug fix).
I would again argue that all of these plugin implementations are owned by SIG testing while contributor experience has previously asserted ownership over the contributor workflow (and similarly googlegroups automation is owned by SIG K8s Infra while contribex has asserted some ownership over some of the groups).
What we lack currently is anything written that actually says "contributor experience owns contributor workflows and you need to get approval for workflow changes" with some examples.
If you're going to unilaterally own implementations, OWNERS files and subprojects are the correct way to declare this, not another doc in k/community.
|
|
||
| --- | ||
|
|
||
| ### Changes to `Label_sync` Path |
There was a problem hiding this comment.
| ### Changes to `Label_sync` Path | |
| ### Changes to `label_sync` Path |
|
|
||
| --- | ||
|
|
||
| ## Out of Scope |
There was a problem hiding this comment.
Do we want to also link https://github.com/kubernetes/community/blob/master/sig-contributor-experience/charter.md#out-of-scope here? To maybe xref?
| - All files under [kubernetes/org/](https://github.com/kubernetes/test-infra/tree/master/config/jobs/kubernetes/org) path | ||
| - [kubernetes/sig-k8s-infra/trusted/sig-contribex-k8s-triage-robot.yaml](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-k8s-infra/trusted/sig-contribex-k8s-triage-robot.yaml) | ||
| - [kubernetes/sig-k8s-infra/trusted/sig-contribex-peribolos.yaml](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-k8s-infra/trusted/sig-contribex-peribolos.yaml) | ||
| - [kubernetes/sig-k8s-infra/trusted/sig-k8s-infra-groups.yaml](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-k8s-infra/trusted/sig-k8s-infra-groups.yaml) |
There was a problem hiding this comment.
Erm, this is SIG K8s Infra? I wouldn't expect changes to keeping this automation running to require input from other sigs, this is a technical implementation.
|
|
||
| ### Changes to Prow CI Jobs and Their OWNERS Files | ||
|
|
||
| Changes to the definition of the following Prow CI jobs files as well as their respective OWNERS files, owned directly or indirectly by SIG ContribEx: |
There was a problem hiding this comment.
Many of these changes are going to be technical in nature.
Instead, what I'm looking for is a document outlining what it is that makes a change something SIG Contribex should review, I.E. "changes that impact contributor workflows / contributor facing behaviors need contribex tech lead review" or something like that.
It is not realistic to unilaterally review all changes to all of these files, plenty of changes will just be e.g. updating to the latest builds and should not require bottlenecking on contribex TLs.
But right now if I tell people "you need contribex review for this contributor facing workflow change" there's no actual written reference for this, and I'm not sure how many people in the project are aware of any such policy.
|
Thanks for the draft! I don't think this is quite what I was expecting 😅 , commented more above |
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
Follow up item from kubernetes/test-infra#32681
/assign @cblecker @MadhavJivrajani @BenTheElder
Reviewers note
This policy document is pretty much an early draft, and possibly listing more areas than what actually falls under ContribEx.
(Please highlight areas that needs to be removed from the list along with all other review comments. Thank you.)