Why users cannot create Issues directly

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.