-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
chore(issues): update auto-labeling #10682
chore(issues): update auto-labeling #10682
Conversation
Codecov Report
@@ Coverage Diff @@
## main #10682 +/- ##
=======================================
Coverage 86.16% 86.16%
=======================================
Files 196 196
Lines 18351 18351
Branches 3905 3905
=======================================
Hits 15812 15812
Misses 2464 2464
Partials 75 75 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
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.
LGTM!
@@ -1,6 +1,6 @@ | |||
name: Feature request | |||
description: Suggest an idea for Amplify JS | |||
labels: feature-request |
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.
Why not keep feature-request
?
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.
Would it make sense to have both pending-triage
& feature-request
to make sure that feature requests get surfaced in our triage process, or is pending-triage
more just for bugs?
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.
Removing feature-request is for forcing DXE's to actually look into the issue and read them before it gets labeled as a feature request. Currently if an issue is opened from the feature-request template it is automatically labeled and that might not always be accurate. This would also standardize the process across repos, CLI team already does it this way
pending-triage
to me means someone from Amplify has either not looked at it or is currently looking into it to make a decision on it's status
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.
But cannot help the DXE's to know to prioritize the ones that are pending-triage & bug
before pending-triage & feature-request
?
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.
This won't effect the priorities, but this enforce us to label things correctly and not let new feature-request
get lost in the repo without ever being noticed.
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.
Hi @elorzafe - not having automatic labels will ensure the DXE team is validating all opened issues and checking whether it actually is a feature-request. We've had at least 20 issues we've re-labeled in the last month.
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.
LGTM thanks @tannerabread 🎖️
Description of changes
Changes the auto-labeling for new issues/feature-requests/questions to include
pending-triage
and removes the auto-labeling offeature-request
Issue #, if available
All of them
Description of how you validated changes
Ran all tests with
yarn run test
in root of project on localChecklist
yarn test
passesBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.