Exclude relnotes issues from going in the triage queue

[apiraino]

We have too many open issues (629, at the time of writing) that are labeled with needs-triage, we cannot keep up with them, we don't see what really needs to be triaged.

For a start, all issues that are about release notes probably don't need this label.

For more context, read this Zulip topic.

CC'ing interested groups, I'd like to hear an opinion if this is fine
cc @rust-lang/triage
cc @rust-lang/release

thanks

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Fallback group: @Mark-Simulacrum, @jieyouxu
• @Mark-Simulacrum, @jieyouxu expanded to Mark-Simulacrum, jieyouxu
• Random selection from Mark-Simulacrum, jieyouxu

[apiraino]

I am also thinking about adding more exceptions for some tracking issues. But we'd first look 1) if there many tracking issues that are also labeled with needs-triage and 2) if for some class of tracking issues this label is actually useful

[jieyouxu]

I think these are safe to not auto-apply needs-triage on issue creation, now that we pre-aggregate the relnotes for next stable release in a central tracking issue.

Thanks
@bors r+ rollup

View changes since this review

[rust-bors]

📌 Commit 0115ce2 has been approved by jieyouxu

It is now in the queue for this repository.

[Urgau]

I disagree with this change, needs-triage is useful indicator that something needs to be done on relnotes issues, like writing/updating the relnote entry.

Everytime I'm pinging on one of them, I update the content and labels so I know the action as been done.

[jieyouxu]

I disagree with this change, needs-triage is useful indicator that something needs to be done on relnotes issues, like writing/updating the relnote entry.

Everytime I'm pinging on one of them, I update the content and labels so I know the action as been done.

Hm, maybe. We had like hundreds of them still with needs-triage, is it really useful signal wise?

[jieyouxu]

Some discussions
@bors r-

[rust-bors]

This pull request was unapproved.

View changes since this unapproval

[Urgau]

We had like hundreds of them still with needs-triage, is it really useful signal wise?

It seems clear that most of them are not being removed, and that indeed reduce the usefulness of it.

Maybe instead of not adding the label at we should encourage people to remove it (or maybe even have triagebot remove it as soon as someone updates the issue body)?

[jieyouxu]

Maybe instead of not adding the label at we should encourage people to remove it (or maybe even have triagebot remove it as soon as someone updates the issue body)?

Seems reasonable. If triagebot could remove it if someone updates the issue body, I think that'd improve the signal-to-noise ratio quite a bit.

[LFS6502]

We had like hundreds of them still with needs-triage, is it really useful signal wise?

It seems clear that most of them are not being removed, and that indeed reduce the usefulness of it.

Maybe instead of not adding the label at we should encourage people to remove it (or maybe even have triagebot remove it as soon as someone updates the issue body)?

Yeah. most of these issues are effectively triaged already, the label means nothing to me (on issues).

[Urgau]

If triagebot could remove it if someone updates the issue body, I think that'd improve the signal-to-noise ratio quite a bit.

I just looked at doing this, and it would be unfortunately highly non trivial given that we would have to do it only for needs-triage+relnotes-tracking-issue, but the current is for needs-triage alone. Quite a bit of complexity.

If triagebot ever gains that feature I would expect it to be used for needs-triage, but in the meantime I won't block this PR moving forward if others wants it.

[Urgau]

relnotes-perf and relnotes-blogpost are only uses in connection with relnotes-tracking-issue and I believe are never set at opening time.

As for relnotes it's set on PRs not issues, so it has no effect with new_issue = true.

Suggested change

	"relnotes",
	"relnotes-perf",
	"relnotes-tracking-issue",
	"relnotes-blogpost",
	"relnotes-tracking-issue",

View changes since the review

[xizheyin]

We could use two separate sets of status for release note and issue. one indicates that release notes still need to be written, and the other indicates that the issue hasn't been triage. For example, S-needs-relnotes and needs-triage.