Triage label is no longer added to issues

[not-an-aardvark]

Now that we use issue templates with labels on the eslint/eslint repo, issues created by non-collaborators usually have labels added to them automatically. As a result, the bot no longer adds the triage label to them.

Is this desirable? I think it depends on the purpose of the triage label:

• If the purpose is to signal that a team member needs to investigate what type of issue it is in order to add the appropriate labels, then the triage label is mostly obsolete and the bot doesn't need to add it anymore.
• If the purpose is to signal that a team member should reply to an issue since it hasn't received a human response yet, then this is a bug and we should make sure to always add the triage label to issues created by non-collaborators.

[kaicataldo]

If the purpose is to signal that a team member should reply to an issue since it hasn't received a human response yet, then this is a bug and we should make sure to always add the triage label to issues created by non-collaborators.

I think having something that signals to us maintainers that an issue hasn't had a human response yet has been valuable to find issues that fall through the cracks, but I wonder if it's really worth the overhead. If this is behavior we still want, we could also potentially add a feature to the bot that pings a new issue when a maintainer hasn't responded in x days. This would mean we wouldn't have to go through and manually remove the triage issue from issues already labeled on creation.

[nzakas]

When did this change? I would have expected us to discuss as a team whether we wanted to automatically assign issue labels when they are opened and what those labels should be. I'm not in favor of the way this is currently set up.

• triage was set up as a way to indicate that a team member hasn't yet looked at the issue.
• evaluating was set up as a way to indicate that a team member has looked at the issue and the issue is now being considered for acceptance.
• accepted was set up as a way to indicate that the team has reviewed the issue and has decided it can be included.

I think the automatically added labels now obfuscate what was a pretty clear progression for issues.

At a minimum, each issue template should add triage instead of evaluating. I'd argue we still need triage because people don't always use the correct template when opening issues, so we still need to verify whether someone using the bug template is actually reporting a bug, for example.

[not-an-aardvark]

This changed in eslint/eslint#11163. Based on the three approvals on that issue and the discussion about the new feature in the team chatroom, it seemed like people were generally in favor of doing something like this. (In the past, we haven't generally required TSC approval for minor changes to issue templates.)

To be clear, the omission of the triage label was an unintended consequence of this change. The original intent was that the bot would continue to add the triage label to new issues, and the additional labels would just save the time of having a human parse the template to figure out what type of issue something is. (edit: I've created eslint/eslint#11182 to ensure "triage" is added.)

The current description of the "evaluating" label on the ESLint repo says, "The team will evaluate this issue to decide whether it is worth adding." My understanding is that "evaluating" doesn't necessarily imply that an issue has already been seen, just that it hasn't been accepted yet.

[nzakas]

Ah thanks, I missed the PR. Even so, I think an email to the team after the fact would have been helpful because of how it changed the issue triaging process. I know I usually go in and filter for "triage" to see which issues need to be looked at. So while I agree that issue template changes shouldn't need a full discussion, I think anything that changes a process should be discussed somewhere with a bit more visibility.