4 ms·

The trouble here is that github issues is crap. Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed"

The trouble here is that github issues is crap. 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. Github issues is mostly a discussion system that was so inadequate that they supplemented it with another discussion system.

codeflo 10mo ago
> 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?
- trinix912 10mo ago
  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 10mo ago
    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 10mo ago
  This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.
  - dymk 10mo ago
    How is that different from other bug tracking systems? The devs have to triage submitted tickets there too
  - philipallstar 10mo ago
    That's always the case. Who else should triage?
  - Thorrez 10mo ago
    Isn't that basically what Ghostty is doing also?
  - Aurornis 10mo ago
    There are several automation solutions for GH issues. You could have an automatic “unconfirmed” tag applied to every user-created issue if you wanted.
    - eqvinox 10mo ago
      RFC1925¹, section 2(3): With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. Translation: sure, you can make this work by piling automation on top. But that doesn't make it a good system to begin with, and won't really result in a robust result either. I'd really rather have a better foundation to start with. ¹ https://www.rfc-editor.org/rfc/rfc1925 https://www.rfc-editor.org/rfc/rfc1925
      - stonogo 10mo ago
        I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.
        eqvinox 10mo ago
        > I hate to break it to you, but all the other ticket systems do this by piling automation on top as well. The rebuke to your comment is right in your comment: "other ticket systems do this by…" The ticket system does it. As in, it has it built-in and/or well integrated. If GitHub had the same level of integration that other ticket systems achieve with their automation, this'd be a non-issue. But it doesn't, and it's a huge problem. P.S.: I hate to break it to you, but "I hate to break it to you, but" is quite poor form.
- darkwater 10mo ago
  > 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.
- eqvinox 10mo ago
  > 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 10mo ago
    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 10mo ago
  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 10mo ago
  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 10mo ago
    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.
christophilus 10mo ago
I take the Basecamp philosophy of, “If it’s important enough, we won’t be able to ignore it, and it’s ok for anything else to fall through the cracks until someone feels like working on it.” Well, that’s a paraphrase, but I remember reading that rough idea on their blog years ago, and it strikes me as perfectly fine for many kinds of projects.
alexpotato 10mo ago
Having used many issue trackers over the years (JIRA, custom tools, GH Issues), I've found GitHub issues to be very usable. Especially with the new features added last year (parent tickets, better boolean search etc) although I'm not sure if you need to opt in to get those. In fact, it's become our primary issue tracker at work.
Fabricio20 10mo ago
> 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. All of this is possible on GitHub issues and is in fact done by many projects, by this metric I dont see how GitHub Issues is any different than say, JIRA. In both cases, as you mentioned, someone needs to triage those issues, which would, of course, be the developers as well. Nothing gained, nothing lost.
ChuckMcM 10mo ago
Discussion systems all the way down :-). This is a fair assessment of the github issues system. I suspect that because git(1) can be a change control system for anything there is never any hope of making an effective issue tracker for a particular thing it is being used to manage change on. The choice the project made to allow the developers to determine when something was an issue is essentially adding a semantic layer on top of issues that customizes it for this particular corpus of change management.

codeflo 10mo ago

> 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?

trinix912 10mo ago
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 10mo ago
  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 10mo ago
This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.
- dymk 10mo ago
  How is that different from other bug tracking systems? The devs have to triage submitted tickets there too
- philipallstar 10mo ago
  That's always the case. Who else should triage?
- Thorrez 10mo ago
  Isn't that basically what Ghostty is doing also?
- Aurornis 10mo ago
  There are several automation solutions for GH issues. You could have an automatic “unconfirmed” tag applied to every user-created issue if you wanted.
  - eqvinox 10mo ago
    RFC1925¹, section 2(3): With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. Translation: sure, you can make this work by piling automation on top. But that doesn't make it a good system to begin with, and won't really result in a robust result either. I'd really rather have a better foundation to start with. ¹ https://www.rfc-editor.org/rfc/rfc1925 https://www.rfc-editor.org/rfc/rfc1925
    - stonogo 10mo ago
      I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.
      - eqvinox 10mo ago
        > I hate to break it to you, but all the other ticket systems do this by piling automation on top as well. The rebuke to your comment is right in your comment: "other ticket systems do this by…" The ticket system does it. As in, it has it built-in and/or well integrated. If GitHub had the same level of integration that other ticket systems achieve with their automation, this'd be a non-issue. But it doesn't, and it's a huge problem. P.S.: I hate to break it to you, but "I hate to break it to you, but" is quite poor form.
darkwater 10mo ago
> 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.
eqvinox 10mo ago
> 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 10mo ago
  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 10mo ago
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 10mo ago
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 10mo ago
  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.

christophilus 10mo ago

I take the Basecamp philosophy of, “If it’s important enough, we won’t be able to ignore it, and it’s ok for anything else to fall through the cracks until someone feels like working on it.” Well, that’s a paraphrase, but I remember reading that rough idea on their blog years ago, and it strikes me as perfectly fine for many kinds of projects.

alexpotato 10mo ago

Having used many issue trackers over the years (JIRA, custom tools, GH Issues), I've found GitHub issues to be very usable. Especially with the new features added last year (parent tickets, better boolean search etc) although I'm not sure if you need to opt in to get those. In fact, it's become our primary issue tracker at work.

Fabricio20 10mo ago

> 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. All of this is possible on GitHub issues and is in fact done by many projects, by this metric I dont see how GitHub Issues is any different than say, JIRA. In both cases, as you mentioned, someone needs to triage those issues, which would, of course, be the developers as well. Nothing gained, nothing lost.

ChuckMcM 10mo ago

Discussion systems all the way down :-). This is a fair assessment of the github issues system. I suspect that because git(1) can be a change control system for anything there is never any hope of making an effective issue tracker for a particular thing it is being used to manage change on. The choice the project made to allow the developers to determine when something was an issue is essentially adding a semantic layer on top of issues that customizes it for this particular corpus of change management.