3 ms·

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

by asdfaoeu 9mo ago

dymk 9mo ago
How is that different from other bug tracking systems? The devs have to triage submitted tickets there too
philipallstar 9mo ago
That's always the case. Who else should triage?
Thorrez 9mo ago
Isn't that basically what Ghostty is doing also?
Aurornis 9mo 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 9mo 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 9mo ago
    I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.
    - eqvinox 9mo 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.
      - stonogo 9mo ago
        No, it's not that well integrated. They don't call it 'tags' but they work exactly the same way. JIRA, the most commonly cited example in this thread, has a whole separate engine for it and your JIRA admin builds the ticket flow manually. All the way back in RT this sort of thing was handled by a cron job. Github leveraging actions to accomplish this isn't much of a difference. P.S. I didn't ask
        deleted 9mo ago
        [deleted]
        deleted 9mo ago
        [deleted]
IshKebab 9mo ago
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.
- lsbussell 9mo ago
  There’s a one-click button to convert from discussion to issue (and vice versa). It’s hardly more work. But I do feel like discussions are kind of hidden and out of the way on GitHub. On repos I maintain, I use an “untriaged” label for issues and I convert questions to discussions at issue triage time.

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

dymk 9mo ago

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

philipallstar 9mo ago

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

Thorrez 9mo ago

Isn't that basically what Ghostty is doing also?

Aurornis 9mo 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 9mo 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 9mo ago
  I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.
  - eqvinox 9mo 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.
    - stonogo 9mo ago
      No, it's not that well integrated. They don't call it 'tags' but they work exactly the same way. JIRA, the most commonly cited example in this thread, has a whole separate engine for it and your JIRA admin builds the ticket flow manually. All the way back in RT this sort of thing was handled by a cron job. Github leveraging actions to accomplish this isn't much of a difference. P.S. I didn't ask
      - deleted 9mo ago
        [deleted]
      - deleted 9mo ago
        [deleted]

IshKebab 9mo ago

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.

lsbussell 9mo ago
There’s a one-click button to convert from discussion to issue (and vice versa). It’s hardly more work. But I do feel like discussions are kind of hidden and out of the way on GitHub. On repos I maintain, I use an “untriaged” label for issues and I convert questions to discussions at issue triage time.