- Ghosttyリポジトリでは、ユーザーが直接Issueを作成できず、まずGitHubのDiscussionsで議論を開始する必要がある
- プロジェクトでは、バグや機能要望の議論にIssueトラッカーを使用せず、すべての議論はDiscussionsで行われる
- 議論が十分に具体化され、実行可能な項目として整理されると、管理者がそれをIssueに変換する
- この方式は、メンテナーとコントリビューターが実際に作業可能なIssueを素早く見つけられるよう支援する仕組みである
- 報告の大半が、ユーザー環境の問題や誤解、未実装機能の要望であるため、この手順はプロジェクトの品質管理において重要である
Issue作成制限ポリシー
- Ghosttyリポジトリでは、ユーザーが直接Issueを作成できない
- その代わり、まずGitHubのDiscussionsで問題や提案を共有する必要がある
- 管理者が議論を確認し、明確に再現可能な問題だと判断した場合にIssueへ変換する
- この方式は、Issueトラッカーに実際に作業可能な項目だけを含めた状態に保つための仕組みである
- すべてのIssueがすでに具体化された状態にあるため、コントリビューターはすぐに作業を始められる
Issueトラッカー運用原則
- Ghosttyは、Issueトラッカーを議論や機能要望のためには使用しない
- 機能要望や一般的な質問はDiscussionsで扱う
- Issueには、明確に定義されたバグや実行可能な作業項目だけを含める
- このアプローチは、オープンソースプロジェクトの保守経験に基づいて形成された運用原則である
- 過去の経験では、ユーザー報告の80〜90%は実際のバグではなく、誤解や環境の問題だった
- 残りの大半は未実装機能の要望であり、追加の仕様策定が必要な場合が多かった
メンテナンス効率の向上
- Discussionsの段階を経ることで、メンテナーは検証済みの問題だけをIssueとして管理できる
- 不要な重複報告や誤ったバグレポートを減らせる
- Issue一覧がすぐに着手可能な項目中心に整理される
- ユーザーは、有効な問題を見つけても追加作業をする必要がない
参考文書
- 詳しい手順とコントリビューション指針はCONTRIBUTING.mdファイルで確認できる
- 該当文書には、Discussionsへの参加方法とIssue変換の基準が明記されている
3件のコメント
Hacker Newsの意見
100%同意。他人のプロジェクトであれば、Issueとして扱うかどうかの判断権限は全面的にその人にある
大きなプロジェクトほど、メッセージを読まない人、妙な要求をする人、さらにはAIでCVEを水増しするケースまで出てくる
ユーザーがエラーの意味を知らなくても、最低限どんなエラーが出たかは伝えるべきだ
以前テスト時に「broken pipe error」と明記したのに、エンジニアが「再現不可」として閉じ、その同じエラーを理由に再現できないと言っていたのを覚えている
ほとんどのトラッカーは「unconfirmed」のような状態で分類できるが、Githubは単純な議論システムなので管理が難しい
4時間かけてコードと根拠を示して反論したのに、返ってきた答えは「shrugs AI」だった
「Facebookization」によって数回クリックすれば全部済むという認識が生まれ、今は「LLMization」によってそれがさらにひどくなりそうだ
専門的なソフトウェアにはこうしたアプローチは適していないが、期待値はすでにそのように形成されている
Ghosttyが議論を通じてリクエストを分類するのはユニークだが有効なアプローチだ
メモリリーク調査が複数のプラットフォームに散らばっている
Xリンク1, Xリンク2, 議論1, 議論2
まだ正式なIssueには昇格していない
8GBのシステムでもターミナルを数回起動しただけでメモリ不足になった
Footは機能は少ないが、はるかに安定していた
2つ目のリンクは単なる論争の試みに見える
Claude Codeとログを分析して暫定的に修正したところ、今では10回に1回しか再現しない
誰かが追加調査するときの助けになればと思う
統合GPUでも問題が起きるのに、いつもGTKかNvidiaのせいにされる
「Issues」と「Discussions」の区別は非効率的だと思う
重複検索が必要だし、チケットの移動もできない
メールでフォローアップすると通知が途切れてしまう
だから自分のプロジェクトではDiscussionsを無効にしている
本物のバグならその時点でIssueに変換すればいい
管理者が「bug」ラベルを付ければ十分だ
議論が整理された段階でIssueを作成すればいいのだから
通知も維持される
Pythonコミュニティの一部の大規模プロジェクトもこうした方式を使っている
ただ、パワーユーザーの立場からするとバグ報告の過程が煩雑だ
「うちのプロジェクトは完璧だ」と言わんばかりの態度が傲慢に感じられる
たいていの通りすがりのバグ報告は役に立たず、むしろノイズだ
本当に貢献したいなら、すでに定義されたバグを修正する方がよい
報告方法に制限を設けるのは当然だ
「すべてのIssueは作業準備完了の状態であるべきだ」という主張に対して、
「それなら『ready-to-be-worked-on』タグを付ければいいのでは？」という質問が出た
このシステムの方がはるかに成功していた
だから開発者専用の空間とユーザー空間を分けたのだ
Issuesは規模が大きくなると管理不能になる
Discussionsをフィルターとして使うのが効率的だ
Githubの2つの機能はUIがほぼ同じだ
ただしDiscussionsにはアップボート機能がある
curl/curl/issues
この方式をデフォルト設定にすべきだという意見もある
コミュニティが議論を、コントリビューターがIssueを担当する構造が理想的だ
GitHubのラベルシステムでも十分に処理できる
GitHubラベル管理ドキュメント
Natural experimentのようなものだ
ユーザー投稿ポリシーには同意する
閉じられた議論を見ると閉じられたIssueと似ているが、少なくともIssueタブのノイズは減る
Ghosttyの閉じられた議論一覧
多くの議論はその段階まで進まないが、ユーザーの問題は解決される
この分離構造はかなり賢い設計だと思う
実際には「Issueを開けない」というのはGitHubの機能ではなく、
「新しいIssueを開かずDiscussionsを使ってほしい」というテンプレートの案内文にすぎない
他のプロジェクトでもこうした方式を見たことがあるが、
議論を出発点にする構造はかなり合理的に見える
ただし多くのプロジェクトはまだGitHub Discussionsを有効化していない
そのディスカッションは、Issueと何が違うのでしょうか？ Issueは「バグ」だけではありません。バグでも、機能提案でも、PRでも……議論する価値のある話題ならIssueです。
議論する価値がないなら、閉じればいいのです。
ディスカッションとIssueに違いがあるからではなく、単に別々のタブに分かれているほうが好みに合っていたのでしょう。
Issueタブに一種のToDoリストとディスカッションの両方を投稿し、それをタグで管理するのか、
vs
IssueタブはToDoリスト専用、ディスカッションはディスカッション専用として使うのか