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

Update Python labels and remove unnecessary ones #15893

Merged
merged 1 commit into from
Jun 3, 2024

Conversation

vyasr
Copy link
Contributor

@vyasr vyasr commented May 30, 2024

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

  • I am familiar with the Contributing Guidelines.
  • New or existing tests cover these changes.
  • The documentation is up to date with these changes.

@vyasr vyasr added improvement Improvement / enhancement to an existing function non-breaking Non-breaking change labels May 30, 2024
@vyasr vyasr self-assigned this May 30, 2024
@vyasr vyasr requested a review from a team as a code owner May 30, 2024 20:20
@vyasr vyasr requested a review from AyodeAwe May 30, 2024 20:20
Copy link
Contributor

@bdice bdice left a 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.

@vyasr
Copy link
Contributor Author

vyasr commented May 30, 2024

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!

@bdice
Copy link
Contributor

bdice commented May 30, 2024

I thought the point of these labels was to have a way to find historical PRs that touch CI files (edit: besides git blame). Are there other ways to use labels besides this kind of categorization?

@vyasr
Copy link
Contributor Author

vyasr commented May 30, 2024

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.

@bdice
Copy link
Contributor

bdice commented May 31, 2024

I thought some more. If you think removing the ci / conda labels makes things easier / cleaner, go ahead and delete them. It's not important to me.

@vyasr
Copy link
Contributor Author

vyasr commented Jun 3, 2024

/merge

@rapids-bot rapids-bot bot merged commit 4a0b591 into rapidsai:branch-24.08 Jun 3, 2024
70 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Improvement / enhancement to an existing function non-breaking Non-breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants