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

Meta issue: Clarify the intent of the "Needs-Triage" label, notably with respect to "Issue-Enhancement", and use it consistently going forward. #19731

Open
mklement0 opened this issue Jun 2, 2023 · 3 comments
Assignees
Labels
Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif Issue-Enhancement the issue is more of a feature request than a bug Needs-Triage The issue is new and needs to be triaged by a work group.

Comments

@mklement0
Copy link
Contributor

mklement0 commented Jun 2, 2023

Summary of the new feature / enhancement

The description of the Needs-Triage label currently reads:

The issue is new and needs to be triaged by a work group.

However, the first act of triage comes before any working-group action: namely identifying which working group to assign, by using the appropriate WG-* label.

  • One way of conceiving of "triage" is to consider this act of assigning a working-group alone as the act of triaging, which would imply that the "Needs-Triage" label should be removed once a "WG-*" label is assigned.

  • Another, extended way of conceiving of "triage" is to only consider it complete after an assigned working-group has jointly decided a feature request's fate, by either rejecting or accepting it, resulting in the appropriate labels getting assigned ("Resolution-Declined" (followed by closure) vs. "Up-for-Grabs", "RFC needed", ...), and that the "Needs-Triage" label should only be removed then.

Ideally - to avoid ambiguity - an automated process would ensure that the "Needs-Triage" label is removed when appropriate.

De facto, the use of "Needs-Triage" is inconsistent:

Among the feature requests whose fate has in effect not be decided, as of this writing 31 do have the "Needs-Triage" label, whereas 62 do not - see the two consecutive comments at #14013 (comment)

Additionally, some issues whose fate has been decided still have that label.

Is anyone paying attention to the 62 in the absence of "Needs-Triage"?


Therefore:

  • Please clarify the exact purpose of the "Needs-Triage" label.
  • Implement automated procedures for its removal based on subsequently assigned labels.
  • For "grandfathered-in" issues that have no "Needs-Triage" label yet haven't had been decided on: either assign this label, or - if a "WG-*" label alone is sufficient - ensure that they all have such labels.

Proposed technical implementation details (optional)

No response

@mklement0 mklement0 added Issue-Enhancement the issue is more of a feature request than a bug Needs-Triage The issue is new and needs to be triaged by a work group. labels Jun 2, 2023
@mklement0
Copy link
Contributor Author

@SteveL-MSFT, please weigh in. Given the sheer number of potentially abandoned issues, I think it's important to get clarity here.

@kilasuit kilasuit self-assigned this Jul 3, 2023
@kilasuit kilasuit added the Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif label Jul 3, 2023
@kilasuit
Copy link
Collaborator

kilasuit commented Jul 3, 2023

I think perhaps need to get the WG's to spend a solid chunk of time on issue triaging across the wide backlog that reaches all way back to 2016. I am whilst I currently have some free time due to being unemployed and looking to get back into work, doing all I can to get through what issues I can, when I can (Would love to be able to dedicate as much of my available time to this - but other things in life right now are stopping some of that) as to help get a handle on this as there is a huge amount of issues for the size of the team, and contributors and lots of things that have over the years had lots of discussion.

Personally Needs-Triage is used in the following

  • Used to identify it's yet to go to WG's
  • Used to identify it's either still with 1 or more WG's and has not yet been looked at by them all.

Bare in mind the WG's contain community members that are volunteering their time (like me) and we are not meeting daily either, so issue triage between all members of the working groups, many of them also implementing fixes/new features and spending time on that is for most of the team perhaps more important.

I am temporarily assigning this to me as to keep a track on this & will spend some time on this as well as general issue maintenance ( again to help get through the backlog of issues) and this is also a discussion point that may be moved across to discussions instead.

Is anyone paying attention to the 62 in the absence of "Needs-Triage"?

I will ask for an update from a overall working group perspective & hopefully some time for a discussion in the next community call.

@kilasuit
Copy link
Collaborator

kilasuit commented Jul 4, 2023

Coming back to this I think the reason why the Needs-Triage Label is missing on those 62 (soon to be less) is that they were likely raised at a point when we didn't have that label. This is just on a quick look into a few of them though.

I intend to go through this and the other WG's too and add labels as needed over the next few days and & will drop a message to the other WG Members about this too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif Issue-Enhancement the issue is more of a feature request than a bug Needs-Triage The issue is new and needs to be triaged by a work group.
Projects
None yet
Development

No branches or pull requests

2 participants