Why users cannot create Issues directly

100% agree.

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.

For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962

but has not graduated to issue worthy status

A couple of big projects in the python space use this approach. Pisses me off as a power user. I find what are clearly bugs all the time, and am forced through a funnel that places the burden on me. Stinks of arrogance to think your project is that rock solid you should add friction for reporting bugs. Especially in “forever v0” projects.

But, I am super lazy.

I'm a fan of this. My own projects on GitHub have an action[1] which autocloses and autolocks any opened issues until they have been reviewed and accepted by me, and I only consider feature requests from sponsors.

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

I agree with the general philosophy about user submissions. Browsing closed discussions looks a lot like browsing closed issues. So I'm not sure that the policy is successfully turning bug reports into discussions. But it's at least keeping Issues free from noise for contributors. Github could do more to nudge users into approaching Discussions differently. https://github.com/ghostty-org/ghostty/discussions?discussio...

Issues simply don't scale. Using discussions as a filter is a good idea.

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

> This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on.

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

I think this is ok. They attempt to add a barrier here, with the attempt to increase the quality of the issue suggested. This may not be the only goal; one may be to have fewer issues raised in total. But there may be several advantages, as well as disadvantages with that approach - it is simply a trade-off.

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!).

I didn’t know GitHub had discussions. This is great

A lot of bugs where I work have the same pattern: one person writes up either what they found to be broken or what they couldn’t do due to a missing feature, then a shadow task is created that describes the bug and what needs to be changed to fix or implement it. I’ve never had problem with both the report and the work-tracker being in the same place but I can see why GitHub calling the product “Issues” might not have been a great name.

2025-12-30 https://x.com/mitchellh/status/2006114026191769924

"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... "

So they are using Issues as a project board to track and manage ongoing work items, but Projects is built for exactly that. May be better in the long term to move project management to Projects and let people file bugs with as little friction as possible.

Is this fundamentally different than just using tags on issues to separate ready to work on things from initial user submissions?

How about using issue types? https://docs.github.com/en/issues/tracking-your-work-with-is...

Seems great to me. Perhaps GitHub should look into incorporating this into the UX somehow? So many projects are issues linking to other issues, I would love to see other projects adopt this to make github task tracking more usable.

Hmm. I 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.

How is the technical block done? Just a bot closing issues or is there some github setting for this?

I wonder if just tagging and filtering automatically via a GitHub setting which currently doesn’t exist could serve the same purpose

I have never worked on projects that give non members write access to our bug tracker.

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.

> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features).

Do I ever make mistakes?

No. It’s the users who are wrong.

Personally, I dig it! Selected parts from linked page:

"""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.[...]"""

This is a good AI application - something which accepts user problem reports and tries to group them together. Maybe even reproducing the bug in a sandbox if the description is good enough. Engaging with the complainant to get more info.

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

(2014)