Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
89 tasks done
dblock opened this issue Feb 14, 2023 · 5 comments
Closed
89 tasks done

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

dblock opened this issue Feb 14, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@dblock
Copy link
Member

dblock commented Feb 14, 2023

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.
This was referenced Feb 14, 2023
@dbwiddis
Copy link
Member

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
Copy link
Member Author

dblock commented Feb 14, 2023

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
Copy link
Member

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
Copy link
Member Author

dblock commented Feb 14, 2023

@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 dblock added enhancement New feature or request and removed untriaged labels Feb 16, 2023
@dblock
Copy link
Member Author

dblock commented Mar 23, 2023

And we're done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants