Why users cannot create Issues directly

Original Article ↗ Hacker News Discussion ↗

An open source terminal project’s decision to block users from creating GitHub issues directly and route all reports through GitHub Discussions first is prompting debate over how best to triage bugs and feature requests. Supporters say this keeps the issue tracker reserved for well-defined, actionable work items and protects maintainers from a flood of misfiled or low-quality tickets, while still giving users a venue for questions and troubleshooting. Critics counter that splitting conversations between issues and discussions adds friction, makes searching harder, and may reflect shortcomings in GitHub’s tooling more than a fundamentally better workflow.

Policy and Rationale

  • Ghostty uses GitHub Discussions for all user reports and ideas; maintainers promote only well-understood, actionable items to Issues.
  • Motivation: on previous projects, 80–90% of “bugs” were misunderstandings, environment/configuration problems, or feature requests, making raw issue queues unmanageable.
  • The goal is for the Issues tab to be a small, high-signal list of clearly scoped work items.

Support and Perceived Benefits

  • Many maintainers and contributors like having a “front-end filter” where users can ask questions, debug environment problems, and refine reports before they become tasks.
  • This avoids the “issue soup” and “stale-bot” patterns, keeps visible issue lists short and motivating, and reduces emotional burnout from closing low-quality issues.
  • Some see it as analogous to traditional trackers with a triage/unconfirmed state, but implemented via two different GitHub primitives.

Critiques and User Friction

  • Power users report frustration at extra steps when they believe a bug is “obviously real,” interpreting the policy as arrogance or needless friction.
  • Others argue that almost all user reports—confusions included—are “real issues” from a product perspective (e.g., docs or UX problems) and shouldn’t be conceptually pushed aside.
  • Some maintainers dislike having two separate trackers to search and follow, calling GitHub’s Discussions/Issues split poorly designed.

Issues vs Discussions vs Labels

  • Several commenters say the same workflow could be achieved with labels or issue types (“triage”, “ready to work on”) and filters, keeping everything in one system.
  • Defenders respond that the hard separation more clearly communicates expectations: Discussions are exploratory; Issues are implementation tasks.
  • Others note that Issues can become noisy if back-and-forth triage happens there; Discussions keep that noise out of the task list.

Example: Memory Leak Debate

  • A suspected Ghostty memory leak illustrates ambiguity: maintainers believe a bug likely exists but cannot reproduce or detect it with tooling.
  • It remains a Discussion rather than an Issue, raising questions about the fuzzy line between “known bug” and “still-under-investigation report,” and reinforcing that the process still requires active triage.