Triage Process Feedback

[mrbobbytables]

Feedback Thread

It has now been a few weeks since the roll-out of the needs-triage labels. Several bumps and issues have been raised in slack and elsewhere.

Please post comments, friction points, and any other feedback in this issue.

---

/sig contributor-experience
/area community-management
/area github-management

[mrbobbytables]

Problem

A PR that touches a file that has a sig label applied by the label key in an OWNERS file will automatically reapply the label if it is removed. This is a feature ensuring that a PR that is updated and touches a new file has the new sig label applied and signals a new group of potential owners needing to approve the PR.

The problem arises during triage when a PR touches multiple areas and a SIG wants to "remove it from their queue" after determining that it should not be evaluated by them.

[lavalamp]

Yeah, this is hitting sig api-machinery repeatedly as there's lots of stuff we co-own with other sigs.

[sftim]

When I triage an issue in k/website eg /triage needs-information, sometimes the issue can be both triaged and needing triage.
Eg at the time of writing kubernetes/website#24657 is labelled needs-triage and triage/needs-information.

Is that the intended behavior? I wasn't sure.

[mrbobbytables]

@sftim That is indeed the intended behavior. There was some back and forth on it, but it was decided that method would be best.

[sftim]

When adding this to a repo, existing issues don't get needs-triage added; is that right? I think I'd prefer it to have the old issues get that label too if they need it.

[thockin]

I am not sure that needs-triage is useful for PRs. At least I don't pay attention to that.

[ehashman]

Feedback from SIG Instrumentation:

• We use and find needs-triage useful for both issues and PRs. It helps us track what issues and PRs we haven't looked at already.
• We are running into some contention issues when things span multiple SIGs. We might want to triage/accept things for SIG Instrumentation, but e.g. maybe SIG API-Machinery disagrees with us. We're not really sure how to manage this.

If anyone wants to see how SIG Instrumentation does our triage sessions, feel free to drop in. We run them biweekly Wednesdays at 9am PT (next one is 2020-12-02 given the KubeCon/US Thanksgiving break).

[nikhita]

When adding this to a repo, existing issues don't get needs-triage added; is that right? I think I'd prefer it to have the old issues get that label too if they need it.

Old issues and PRs will get the needs-triage label if there are any changes on the issue/PR i.e. it is reopened or labels are updated. Unconditionally updating old issues becomes trickier because it could mean that we'd hit the rate limit if there are a lot of issues (which is usually the case for kubernetes repos).

[sftim]

Is there any mechanism for trickling old, open issues into Prow's labelling mechanisms? Even 1 per minute would be useful I think.