search

opensearch-project / .github

Provides templates and resources for other OpenSearch project repositories.
Apache License 2.0
28 stars 71 forks source link

[PROPOSAL] Ensure all new issues have an untriaged label #133

Closed dblock closed 1 year ago

dblock commented 1 year ago

What/Why

What are you proposing?

Ensure that all new issues carry an untriaged label.

What users have asked for this feature?

We use untriaged as a mechanism to know that a human has looked at every new issue and classified it correctly, which is especially important for security issues. Triaging issues is documented in https://github.com/opensearch-project/.github/blob/main/RESPONSIBILITIES.md#triage-open-issues.

What problems are you trying to solve?

Many repos either do not have an untriaged label, or new issues created don't have an untriaged label. This means there may be open issues that are security that nobody has looked at.

What is the developer experience going to be?

  1. Ensure the repo has an untriaged label. The official color for the label is #FBCA04.
  2. Ensure a GH workflow that adds an untriaged label copied from here.
dbwiddis commented 1 year ago

The bug and issue templates at .github (imported by all projects by default) already apply untriaged labels to issues created via those templates (unless intentionally removed by the issue creator before opening the issue). Are those workflows sufficient to meet this goal?

dblock commented 1 year ago

The bug and issue templates at .github (imported by all projects by default) already apply untriaged labels to issues created via those templates (unless intentionally removed by the issue creator before opening the issue). Are those workflows sufficient to meet this goal?

It's sufficient but not robust enough. I found a number of repos (10+) without such templates (deleted or not inherited), and/or no untriaged label.

dbwiddis commented 1 year ago

It's sufficient but not robust enough. I found a number of repos (10+) without such templates (deleted or not inherited), and/or no untriaged label.

Fair, but if the label exists and issues are being triaged, is that sufficient to meet the intent of this campaign?

I ask because the vast majority of issues created on our repo are by maintainers themselves, and we often intentionally remove the pre-populated untriaged label to reduce noise. This workflow will add it back and force us to remove it again, or more likely we'll forget and we'll end up with real untriaged issues hidden amongst our future feature planning.

dblock commented 1 year ago

@dbwiddis up to you, but I prefer the workflow because it is more future proof when you have external contributors, and it supports reopening issues and issues being transferred

dblock commented 1 year ago

And we're done!