WIP: add guiding policy for contribex review on test-infra repo

[Priyankasaggu11929]

Follow up item from kubernetes/test-infra#32681

As a follow up, they (ContribEx TLs) are working on a more descriptive policy for changes to prow contribution workflows so that there is more clarity in this space.

/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.)

[k8s-ci-robot]

[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:

• sig-contributor-experience/OWNERS [Priyankasaggu11929]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Priyankasaggu11929]

/hold for reviews

[MadhavJivrajani]

Thanks for starting this @Priyankasaggu11929 ❤️
Leaving a few initial comments!

[MadhavJivrajani]

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.

[BenTheElder]

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.

[MadhavJivrajani]

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.

[BenTheElder]

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.

[MadhavJivrajani]

Suggested change

	### Changes to `Label_sync` Path
	### Changes to `label_sync` Path

[MadhavJivrajani]

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?

[BenTheElder]

... I'd sort of expect documents about test-infra specific changes to be in test-infra?

Sections like the list of files seem very likely to get out of date across repos

[BenTheElder]

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.

[BenTheElder]

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.

[BenTheElder]

Thanks for the draft! I don't think this is quite what I was expecting 😅 , commented more above

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale