本篇文章更新時間：2026/01/03
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
內容目錄
Ghostty 不讓使用者直接開 Issue？其實是更有效率的維運策略
從官方討論串讀到的專案管理心法
編輯前言：Ghostty 官方在討論串中明確說明為什麼不開放使用者直接建立 Issue。看似限制，背後其實藏著對開源專案維護流程的深思與取捨，非常值得其他開源作者參考。本篇內容整理自原文：Why users cannot create Issues directly。
核心觀點 (Key Takeaways)
- Ghostty 將「問題討論」與「可執行 Issue」嚴格分流：討論先走 Discussions，成熟後才轉成 Issue。
- 超過八成使用者認為的 bug，實際上是誤會、環境問題或設定錯誤。
- 大多數功能需求（feature requests）其實都還不夠明確，需要維護者協助收斂。
深入解析
Ghostty 的維護者在原文中強調，他們不使用 GitHub Issues 來收集問題或想法，而是以 Discussions 作為第一站。換句話說：
「Once a discussion reaches a point where a well-understood, actionable item is identified, it is moved to the issue tracker.」
也就是只有當討論清楚到可以直接執行、能立刻著手修復或實作時，才會被轉換成 Issue，並由維護者負責建立。這個流程大幅提升了 Issue 的純度，讓任何進到 Issue 列表的項目都能讓貢獻者直接動手，而不是先花時間追查細節。
-
為什麼不能讓使用者直接開 Issue？
Ghostty 的經驗顯示，使用者回報的八到九成「bug」其實不是真正的 bug，而是環境因素或不了解功能導致的誤會。 -
那功能需求呢？
多數功能請求都是「模糊的」，例如「可以做得更好嗎？」或「能不能支援某某行為？」，實際上還需要維護者引導，才能形成可執行的 Issue。
因此，Ghostty 用 Discussions 來「過濾」、「釐清」、「收斂」問題，最後只有真正明確的內容才會進到 Issue。對使用者而言，只要問題是有效且明確的，最終也會由維護者協助轉成 Issue，不會增加額外成本。
筆者心得與啟發
看完原文後，我覺得 Ghostty 的這套做法其實非常成熟，尤其適合高流量、高需求的開源專案。許多專案的 Issue 常常被大量無效回報淹沒，維護者光是分類、檢查、回覆就耗掉大量時間。
Ghostty 的做法等於是把 Issues 變成「可直接開工的工作清單」，而把所有不確定的內容都導入 Discussions 先整理。如果我是管理一個快速成長的專案，這種「分層處理」的方式其實更加有效率。
對一般使用者而言，雖然要先從 Discussions 開始好像多一個步驟，但換個角度看：能讓維護者更快定位問題，也能讓專案維持健康的開發節奏，這筆小小的成本其實很值得。