Personally, I find the distinction between “issues” and “discussions” annoying.

For one, it duplicates the efforts in checking for prior reports. I might try 5–6 sets of keywords, but now I have to do so for 2 separate trackers.

Tickets cannot be moved between trackers, so instead folks resort to duplicating it and moving discussions… which is entirely opaque if you’re following up via email: you won’t get any more notifications and your future replies are silently discarded.

As a maintainer, having two trackers per project never made sense to me, so I’ve disabled discussion everywhere.

This is mostly a criticism of how GitHub implemented this feature, not of the decision taken here.

> I find the distinction between “issues” and “discussions” annoying

The benefit is that all users who just ask for help, assistance, or are unable to install or use the software now have a place to ask.

You shouldn't create an issue just because you get an error when installing, but it might be beneficial to still ask for help.

If it is indeed a bug, then create a ticket, linking to the discussion.

Normally, too many issues are user errors.

At the very least I think what matters here is the process. The same exact process could be implemented via, for example, issue labels. It would not be hard for maintainers to search for issues with label "bug", which only maintainers can assign. There are clear UX tradeoffs between the two approaches.

> Tickets cannot be moved between trackers

You can convert an issue to a discussion and vice versa, so no duplication is needed and your notification should be preserved.

Or do you mean something else?

Why would checking be duplicated? One would need to check only the discussions in this case, since issues will be created from discussions once something is ready to be worked on (as I understood it)

I've been annoyed at this distinction myself when trying to troubleshoot problems with other Github-hosted software. I actually think the distinction Ghostty is making here where the Discussion section is open for anyone to bring up an issue with a project, and the Issues section is locked down to official maintainers and is only used for tracking well-scoped planned changes to the software (which might arise from a user-initiated discussion about a problem) makes a great deal of sense. I haven't seen any other Github-hosted project which organizes itself in exactly this way but I have zero problem with it as a user of Ghostty myself.

behold the best way to search github issues. Using Google or whatever decent search engine:

    site:https://github.com/org/repo key words