[codeflo]

> Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc.

As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky?

[darkwater]

> Would you consider that too clunky?

Absolutely. It's a patch that can achieve a similar result, but it's a patch indeed. A major features of every ticketing system, if not "the" major feature, is the ticket flow. Which should be opinionated. Customizable with the owner's opinion, but opinionated nonetheless. Using labels to cover missing areas in that flow is a clunky patch, in my book.

[trinix912]

IMO it still has poor discoverability, constant filtering between the triage status flags and non-flagged stuff, stuff that might not have been flagged by accident, reporters putting tags on issues themselves, issues can only be closed by non-admins rather than truly deleted, random people complaining about this or that on unrelated tickets...

It all stems from the fact that all issues are in this one large pool rather than there being a completely separate list with already vetted stuff that nobody else can write into.

[smallnix]

Sounds like it could be fixed by making it configurable to hide all issues without a certain tag (or auto-apply a hiding tag) for the issues "landing page".

[asdfaoeu]

This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.

[dymk]

How is that different from other bug tracking systems? The devs have to triage submitted tickets there too

[Aurornis]

There are several automation solutions for GH issues. You could have an automatic “unconfirmed” tag applied to every user-created issue if you wanted.

[IshKebab]

They're already doing that by moving discussions to issues. In fact it's more work for them because they have to actually create the issue instead of just adding a "confirmed bug" label or whatever.

I guess it probably leads to higher quality issue descriptions at least, but otherwise this seems pretty dumb and user-hostile.

[Thorrez]

Isn't that basically what Ghostty is doing also?

[philipallstar]

That's always the case. Who else should triage?

[eqvinox]

> As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky?

Speaking for another large open GitHub project:

Absofuckinglutely yes.

I cannot overstate how bad this workflow is. There seems to be a development now in other platforms becoming more popular (gitlab, forgejo/codeberg, etc.) and I hope to god that it either forces GitHub to improve this pile of expletive or makes these "alternate" platforms not be so alternate anymore so we can move off.

[Conan_Kudo]

None of the alternative forges have a better issue tracker implementation. For the most part, they are basically copies of GitHub. No hope there. :(

[antonvs]

The classification here is not what type of issue it is, it's whether it's an issue or not. Creating an issue for things that aren't issues is fundamentally broken. There's no way to fix that except by piling bad design on bad design to make it so that you can represent non-issues using issues and have everything still be somewhat usable.

[ericrallen]

Just trying to triage and tag all of them can still be a full-time job’s worth of work in a popular repo.

[pastage]

Having spent only a week triaging Mozilla bug reports I do not see how a different ticketing system makes it easier. It is just hard work.