January 1, 2026
No Issues, No Cry
Why users cannot create Issues directly (Ghostty)
Ghostty puts bugs behind a velvet rope—devs cheer, users squint
TLDR: Ghostty now routes bug reports through Discussions, promoting only clear, reproducible problems to Issues. Commenters loved the cleaner workflow but flagged scattered troubleshooting across X and Discord, pushing GitHub to improve the interface so this velvet rope doesn’t hide real problems or turn bug hunts into platform whack‑a‑mole.
Ghostty just slammed the “no walk-ins” sign on its bug board: you can’t open Issues directly—you start a Discussion, and only crystal-clear, reproducible problems get promoted to the VIP list. The team says most “bugs” are confusion or misconfigurations, and this keeps the to‑do list clean and actionable. The crowd? Loud. xpe popped the confetti with “Personally, I dig it,” while keyle dropped a mic about scale: “Issues don’t scale—filter with discussions.” Fans framed it as maintenance self‑care, fewer drive‑by bug dumps, more focused fixes.
But then came the side-eye. Maxious warned that a memory leak hunt is splintered across Discussions, X/Twitter (https://x.com/mitchellh/status/2004938171038277708) and Discord (https://x.com/alxfazio/status/2004841392645050601), raising fears of bug whack‑a‑mole across platforms. literatepeople asked GitHub to bake this flow into the interface so everyone plays the same game. And 1123581321 called out a vibe mismatch: browsing closed Discussions feels like browsing closed Issues—cleaner lists, sure, but behavior unchanged. The chorus: great housekeeping, risky visibility.
Amid the drama, memes flew: “Issue bouncer at the velvet rope,” “bring a hall pass to report a bug.” The hot take economics: if you spend more time closing Issues than creating them from Discussions, the math wins. Team sanity vs public chaos—choose your fighter.
Key Points
- •Users cannot create Issues directly in the Ghostty repository; they must start with a GitHub Discussion.
- •Ghostty uses Discussions for general discussion and feature requests, reserving the issue tracker for actionable items.
- •Maintainers convert Discussions into Issues once a well-understood, reproducible problem or task is identified.
- •The approach is based on experience that 80–90% of reported bugs are misunderstandings, environment, or configuration issues; many remaining reports are underspecified feature requests.
- •Further procedural details are available in the project’s CONTRIBUTING.md.