[RFC] Issue Triage Workflow improvements for kubernetes/kubernetes

[Stephen Augustus]

Following several discussions across the past year across contributors in SIG Release, Contributor Experience, and PM, we are proposing some provisional improvements to the issue triage process within kubernetes/kubernetes.

tl;dr:

• Create two new labels: needs-triage, triage/ready
• Allow milestone-maintainers to remove the needs-triage label by applying the triage/ready label (similar to how needs-[kind|priority|sig] labels work today)
• Remove unused triage/** labels

We'd like to move on enabling these changes for Kubernetes 1.19, so we're opening the KEP for broader review.

Please note that this is a provisional KEP, so we'll plan to merge and iterate quickly, barring any blocking comments.

The KEP is here: https://github.com/kubernetes/enhancements/pull/1554

Lazy consensus timeout: Thursday, April 9, 5pm US ET

-- Stephen

[Tim Hockin]

On Mon, Apr 6, 2020 at 10:15 AM Stephen Augustus <steph...@agst.us> wrote:
>
> Following several discussions across the past year across contributors in SIG Release, Contributor Experience, and PM, we are proposing some provisional improvements to the issue triage process within kubernetes/kubernetes.
>
> tl;dr:
>
> Create two new labels: needs-triage, triage/ready
> Allow milestone-maintainers to remove the needs-triage label by applying the triage/ready label (similar to how needs-[kind|priority|sig] labels work today)
> Remove unused triage/** labels

Define "unused" here? The existing labels are frequently used and
almost alway wrongly. IMO we should nuke ALL other triage/* labels
* triage/duplicate
* triage/needs-information
* triage/not-reproducible
* triage/support
* triage/unresolved

Plus, we need to make it very clear that folks who are assigning SIGs
MUST NOT clear needs-triage - that is for the SIGs to do

> We'd like to move on enabling these changes for Kubernetes 1.19, so we're opening the KEP for broader review.
>
> Please note that this is a provisional KEP, so we'll plan to merge and iterate quickly, barring any blocking comments.
>
> The KEP is here: https://github.com/kubernetes/enhancements/pull/1554
>
> Lazy consensus timeout: Thursday, April 9, 5pm US ET
>
> -- Stephen
>

> --
> You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOqU-DQcpTrL2zuztU6nPptzb0LaJ09%2ByZQY76eX1edH%3Dz4-bA%40mail.gmail.com.

[Stephen Augustus]

Hey Tim,

I made updates to the KEP earlier today, which were based on your feedback comments, namely (see specifics in bold):

Considerations:

• triage/ready should be considered a placeholder name for the label in this provisional state, depending on what we decide is the most appropriate name.
• There will be an expectation that only SIG members designated to triage issues are applying triage labels. We're considering limiting application of this label to the milestone-maintainers GitHub team.

<snip>

Remove unused triage/** labels

As we're considering reviving the triage/** labels in this workflow, it's important that all labels with this affix are up-to-date, removing any triage/**label deemed to be unused.

The current list of triage/** labels is as follows:

• triage/duplicate
• triage/needs-information
• triage/not-reproducible
• triage/support
• triage/unresolved

We propose here removing the following labels:

• triage/duplicate
• triage/not-reproducible
• triage/unresolved

Which leaves the following set and accompanying definitions:

• triage/needs-information: Issue requires more information (from submitter or SIG) in order to work on it
• triage/ready: Issue has been triaged by a SIG representative and is ready to be worked
• triage/support: Issue has been identified as a support question and should be routed to the appropriate forum

I think those labels are still useful.

Let's take this to review comments on the KEP, so we have everything in one place.

-- Stephen

[Stephen Augustus]

Reminder that we're planning to merge the Issue Triage KEP as provisional tomorrow, Thursday, April 9 at 5pm US ET.

-- Stephen

[Tim Hockin]

What is missing to move to implementable?

> --
> You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOqU-DTH3Wwzxp%3DNJ0vD5W2wh31NtHyLGu7AejgZPNQ23e5M1A%40mail.gmail.com.

[Stephen Augustus]

Not much, IMO.

I've got to clean up/combine these k/test-infra PRs to match the KEP's current state:

• https://github.com/kubernetes/test-infra/pull/16298
• https://github.com/kubernetes/test-infra/pull/16299

The Release Team checklist is largely not applicable here as this isn't code merging into k/k, but some things to do:

• Update the Enhancement issue: https://github.com/kubernetes/enhancements/issues/1553
• Flip the KEP status to implementable
• Choose a go-live date (ASAP)
  
• Update the documentation around triage/** labels, including issue templates
  
• Get approvals on aforementioned PRs
• Broad comms about turning this on
• Release the holds on any open PRs

We're close now that this has already been shopped around in a few places.

I plan to get this done and turned on in the early days of the Kubernetes 1.19 cycle, so O(week or two, if not sooner).

-- Stephen

[Tim Hockin]

Sounds good. Can't wait!