Is it worth adding a default 'new bug'/'untriaged' style label to all new issues?

[RKSimon]

I noticed we don't have the 'new bugs' label at all after the migration, this is probably not a major loss for most of the legacy bugs, but we could do with some way to assist with triaging of new github issues.

It might be useful to automatically tag new issues created on github with a label indicating it is fresh and hasn't been fully triaged yet.

I haven't used github issues much in the past so I might be missing some part of the filtering that already does this.....

[asl]

As of c16ced9 we're adding "help wanted" label to all new issues unless labels are already set.

[nikic]

Could you please create a new label for this purpose? The "help wanted" and "good first issue" are given special semantics by GitHub, and are intended to make certain issues more discoverable for new contributors. While this may coincide with newly filed bugs in some cases, it generally will not. (And new contributors usually cannot participate in bug triage by dint of not being organization members and thus unable to e.g. add labels to issues.)

[asl]

Fair enough. It will be "new issue"

[Quuxplusone]

Over at #53299, @AaronBallman points out (and I quite agree) that the workflow resulting from #52614 is exactly backwards. Newly filed (unconfirmed) issues should not be specially tagged. (The vast majority of bug-filers aren't going to know how to tag their bugs anyway.) Once a bug is confirmed, the (experienced) person who confirms it should label it with the "confirmed" label (just as they used to do on Bugzilla, except that on Bugzilla it was a dedicated status, not a tag).

This has the advantage that "confirmed" never bit-rots: once confirmed, always confirmed.

"New issue," on the other hand, bit-rots: Should ten-year-old issues still be marked "new issue"? Should closed issues still be marked "new issue"? Who is responsible for labeling and unlabeling these issues? (There's no clear answer; that's why a bot had to be invented to do the labeling, and we still don't know what to do about the unlabeling.)

And "new issue" has the opposite-of-bit-rot problem too: new users will never know or care to mark their bugs with "new issue," so you have to maintain a bot to do it. Whereas "confirmed" doesn't have that problem: you mark a bug "confirmed" precisely when you confirm it.

So, I concretely propose that we stop running the "new issue" bot, delete the "new issue" label (including removing it from all 55 closed issues), and apply the "confirmed" label to all issues migrated from Bugzilla that have the everconfirmed flag on Bugzilla.

[RKSimon]

Is there a github way to filter for bugs with no label set? Or are the triagers expected to review based off the emails sent to llvm-bugs?

[EugeneZelenko]

Is there a github way to filter for bugs with no label set? Or are the triagers expected to review based off the emails sent to llvm-bugs?

List of open issues is good enough to find ones without labels.

[Quuxplusone]

@RKSimon: Yes, you can search for is:open -label:confirmed, for example. Obviously that will become more useful once we port the "confirmed" label from Bugzilla. ;) Then you can sort by date to find the newest unconfirmed bugs.

You can also search to find things like "unconfirmed bugs, in the [clang:diagnostics] label, unassigned only, sorted by oldest first." Or "good first issues, unassigned only, sorted by newest first."

[RKSimon]

Closing - the 'confirmed' workflow seems to be working well instead