If it's someone else's project, they have full authority to decide what is and isn't an issue. With large enough projects, you're going to have enough bad actors, people who don't read error messages, and just downright crazy people. Throw in people using AI for dubious purposes like CVE inflation, and it's even worse.

but has not graduated to issue worthy status

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.

But, I am super lazy.

How is this not trivially solved via a "ready-to-be-worked-on" tag?

If you spend more time closing issues than creating them manually from discussions, the math adds up.

The real miss here is that there isn't a way on GitHub to only allow maintainers to create issues, instead we are left with these subpar workarounds.

[1]: https://github.com/LGUG2Z/komorebi/blob/master/.github/workf...

"""Unlike some other projects, Ghostty does not use the issue tracker for discussion or feature requests. Instead, we use GitHub discussions for that. Once a discussion reaches a point where a well-understood, actionable item is identified, it is moved to the issue tracker. This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on.

This approach is based on years of experience maintaining open source projects and observing that 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves.[...]"""

In particular when I maintain an open source project, I have a lack of time in general so I need to move quickly. I actually don't mind issue discussions on my project, but people can not expect me to invest a lot of time into managing all of those; whether this is a discussion or an issue directly, is not so important, but I know that some project owners don't like open issues that remain open for years. It is kind of a difference in philosophy here.

One trade off is that I am not so likely to get involved in such a project. I may start a discussion, but in general I am very chaotic and may never follow up on discussions I started, simply due to lack of time, too many things to do, forgetting too much too (I do keep notes locally, but these files just keep on growing!).

*DO NOT OPEN A NEW ISSUE. PLEASE USE THE DISCUSSIONS SECTION.*

*I DIDN'T READ THE ABOVE LINE. PLEASE CLOSE THIS ISSUE.*

That being said, as long as you still have the discussion tab, auto-deleting all issues by default is not a big deal.

IRL every dev issue tracker needs a front-end bozo filter to handle the low-hanging fruit and the misunderstandings and the failures to RTFM and the cases of PEBCAK.

Issue trackers should be used exclusively for earmarking and tracking the progress of actionable items. This is somewhat similar to the integration between email clients and task managers, like how it's done in Gmail, Zoho, etc. You read the message first. If it requires an action from your side, create a task from it and link them.

There are other projects that do this too. A good example is the 'mise' project. Sourcehut projects use this workflow almost exclusively since it's the default by design. I think sourcehut had if before github did. What I would like to see is better integration between discussions/messages and task/issue lists on all these platforms.

Do I ever make mistakes?

No. It’s the users who are wrong.

There are absolutely bugs that get reported - either in functionality or documentation - but by requiring a level of triage in Discussions before promoting them up to Issues is a great way to keep things more actionable for folks wanting to come in and contribute fixes that the maintainers do agree are needing a fix

"Slop drives me crazy and it feels like 95+% of bug reports, but man, AI code analysis is getting really good. There are users out there reporting bugs that don't know ANYTHING about our stack, but are great AI drivers and producing some high quality issue reports.

This person (linked below) was experiencing Ghostty crashes and took it upon themselves to use AI to write a python script that can decode our crash files, match them up with our dsym files, and analyze the codebase for attempting to find the root cause, and extracted that into an Agent Skill.

They then came into Discord, warned us they don't know Zig at all, don't know macOS dev at all, don't know terminals at all, and that they used AI, but that they thought critically about the issues and believed they were real and asked if we'd accept them. I took a look at one, was impressed, and said send them all.

This fixed 4 real crashing cases that I was able to manually verify and write a fix for from someone who -- on paper -- had no fucking clue what they were talking about. And yet, they drove an AI with expert skill.

I want to call out that in addition to driving AI with expert skill, they navigated the terrain with expert skill as well. They didn't just toss slop up on our repo. They came to Discord as a human, reached out as a human, and talked to other humans about what they've done. They were careful and thoughtful about the process.

People like this give me hope for what is possible. But it really, really depends on high quality people like this. Most today -- to continue the analogy -- are unfortunately driving like a teenager who has only driven toy go-karts."

"Examples: https://github.com/ghostty-org/ghostty/discussions?discussio... "

There doesn't seem to be enough of a separation between the concepts of "issues" and "discussions" to support separating them into two features.

Given that discussions seem more general, it seems like the right path forward would be to have only discussions. Sub-features of issues could be added to discussions.

It looks great. As mentally easy to process as Jira tasks. Or even better, cause it was written by a good "PM", which is not always a case commercially.

Edit: after reading the contributors doc, it seems that feature requests are discussions which should help. Unreproducible bugs, too; although I would wager that a lot of users believe they can reproduce bugs but in fact can't consistently, or believe their feature request is a bug.

It seems this approach is better but still requires someone to sort through the discussions before they're moved to the cleaner issues pile.

One big pile with filters, or a chaotic pile and a clean pile. That seems to be the end result of this, unless I'm missing something.

[0] https://github.com/Barre/ZeroFS

The term "discussion" does not have anything to do with this.

I understand these are all github choices of terms, and it should also be reframed properly by github.

And then there are developers who idly complain about normal participation on the work of issues and coordination of testing and feedback because it sends them a notification that they turned on. Unconstructive bitching drives users and collaborators away. They could solve their notification problem rather than impose a burden and emotional bullshit on everyone else.

However github has no option to close issues to contributors only.

These folks do what we do, they have an issue template called "do not use this". big whoop. People blow through those all day so we're clicking on "convert to discussion" all day.

Github please add this feature!

Just the first thing that popped into my head reading the reasoning. I think it makes a lot of sense to do it like this. Especially for a product which is cross platform that emulates / replaces other known products and on top has extensive configuration options. I also switched over from kitty a couple of weeks back and really like it.

When I have a clear "Issue" which I've already researched, it's a bit of friction, but it doesn't seem like any more work to dump exactly the same text into a Discussion... and yea. Issues becoming a dumping ground is a real issue. This seems like a reasonable strategy / experiment.

Personally, I use GH Issues for my own work, but there’s very few issues, so it’s not a burden. I’m a non-fan of JIRA.

I have seen GH Issues turn into Reddit-like flamefests (every now and then, someone posts a particularly entertaining one, here). Not my idea of productive work.

So this makes me think the developer here just doesn't like the idea of issues being reported on his project.

Who does this project actually serve? The "users", or someone else?

If I'm getting overwhelmed with hundreds of issues per week about some confusion around installation or use, I think those issues are completely justified. Something should probably be fixed if the happy path is this obscure. Pushing this reality into another bucket is not the solution for me.

This includes both our open source project not giving the public access. And our entirely closed source internal projects not giving other developers within the company write access.

This could be useful if not used for enshittification, where you have to get past the chatbot to reach anybody useful.