-
Notifications
You must be signed in to change notification settings - Fork 915
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
Update Python labels and remove unnecessary ones #15893
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm weakly in favor of keeping ci
.
Perhaps we can rename conda
to packaging
and also make it trigger on pyproject.toml
files? No strong feelings, I'm okay with any outcome here so I'll defer to your preferences.
I'd like to stick to somewhat actionable labeling, especially autolabeling. If we can find a good way to make use of the information that an issue has these labels I'd be fine keeping them, I'm open to suggestions! |
I thought the point of these labels was to have a way to find historical PRs that touch CI files (edit: besides |
I regularly make use of labels to find open issues/PRs that need my (or someone else's) attention. Labels can also be used in building automations, such as adding issues to project boards for specific teams or handling auto-assignment (independent of PR/issue creation). I find less use of them for historical purposes tbh. That being said, I'm not opposed to that. If you prefer, I can leave the ci and conda auto-labeling in place for now since those don't really have any negative impact. The main reason I was considering removing them from the auto-labeler is because we were considering removing those labels altogether. In our discussions around improving the triage process and the labels we use, nobody really spoke up for these two being useful, conda in particular. |
I thought some more. If you think removing the |
/merge |
Description
This PR leverages some of the new labels we have for organizing our issues and removes labels that aren't really used at the moment. If reviewers feel strongly I can keep the ci label, but AFAICT that doesn't really get used for anything at the moment and we'll benefit more from leveraging future labels to help direct tasks to the build/infra team vs cudf devs.
Checklist