ハクソク

世界を動かす技術を、日本語で。

ユーザーが直接「イシュー」を作成できない理由

105日前原文(github.com)

概要

  • GhosttyリポジトリではIssueの直接作成は禁止
  • 最初にDiscussionを作成し、議論を進める運用
  • Issueトラッカーは明確な作業項目のみ使用
  • バグ報告や要望の多くは誤解や設定ミスが原因
  • 詳細はCONTRIBUTING.md参照

GhosttyリポジトリでのIssueとDiscussion運用方針

  • ユーザーによるIssueの直接作成は禁止
  • まずGitHub Discussionsで議論を開始する運用
  • Issueトラッカーは議論から明確なアクションが特定された場合のみ利用
  • 他プロジェクトとは異なり、バグ報告や機能要望の議論はIssueトラッカーを使わない方針
  • Discussionsで合意形成後、メンテナーがIssueへ移行
  • この運用により、作業可能なIssueのみがIssueトラッカーに残る
  • 数年にわたるOSS運用経験に基づくベストプラクティス
  • ユーザー報告の8～9割は誤解・環境要因・設定ミスが原因
  • 残りの多くは機能要望であり、バグ（既存機能の不具合）は少数
  • 機能要望の多くは具体性不足のため、メンテナーのガイダンスが必要
  • Ghosttyに関する明確な問題がDiscussionsで特定・再現された場合のみ、メンテナーがIssueへ変換
  • ユーザー側の追加作業は不要
  • 詳細手順やルールはCONTRIBUTING.mdを参照

Hackerたちの意見

問題は単純にスケールしないよね。ディスカッションをフィルターとして使うのはいいアイデアだと思う。もしディスカッションから手動で問題を作るよりも、問題を閉じるのに時間をかけているなら、計算が合うよ。
└
なんでそう言うの？Curl（世界で最も使われているオープンソースソフトウェアの一つだと思うけど）は、現在5つのオープンな問題があるよ。 https://github.com/curl/curl/issues
└
実際の違いって何なんだろう？メンテナとして、本当に問題があるのかどうかを見分けたいなら、結局は全部読まなきゃいけない（トリアージ）。それが時間がかかる理由だよね。ディスカッションをイシューに変えるのが、逆にするよりも楽だとは思えない。どっちもクリック一つだし。GitHubのイシューとディスカッションは、ほぼ同じ機能に見える（UIもほぼ同じで名前が違うだけ）。唯一の利点は、ディスカッションにはトップレベルのアップボート数があることかな。
└
> 「もしディスカッションから手動でイシューを作るよりも、イシューを閉じるのに時間をかけるなら、計算が合うよ。全てのイシューを無視して、2週間後に古くなったから閉じるってやり方なら、もっと計算が良くなる！」これが冗談だったらいいのに、そうじゃないんだよね。
例えば、メモリリークの調査は今、ディスカッションやx/twitter、Discordに散らばってるんだよね。 https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962 でも、まだ問題として扱うには至ってない。
└
それを聞くのは残念だね。メモリリークの問題でGhosttyを諦めざるを得なかったよ。確かに8GBのシステムだったけど、週に数回ターミナルを動かすのには十分なはずなんだ。Footは安定してるけど、Ghosttyの便利機能がないのがちょっと残念。
└
作者は最初のリンクで、報告されたのは2回だけだと言ってるけど、それはおそらく後の2つのリンク（2つのディスカッション）を指してるんじゃないかな。君の2つ目のリンクは、Xのユーザーが炎上を狙ってるように見えるけど、他の返信は私には隠されてる。
ユーザーの投稿に関する一般的な考えには賛成だな。閉じたディスカッションを見て回るのは、閉じた問題を見て回るのと似てる。だから、バグ報告がディスカッションにうまく変わってるかは疑問だね。でも、少なくとも貢献者のために問題がノイズから解放されてるのはいいことだよ。Githubはユーザーがディスカッションにもっとアプローチするように促すために、もっとできることがあると思う。 https://github.com/ghostty-org/ghostty/discussions?discussio...
└
逆のことだと思うけどね。ユーザーの不満はすべてディスカッションから始まるんだ。そこから実行可能なバグ報告が出たら、トラッカーに行く。それが問題リストとして機能するんだ。多くのディスカッションはこのようには終わらないけど、アドバイスや参考を提供することでユーザーの問題を解決することもあるよね。確かに、問題トラッカーでもディスカッションができるし、作業可能な問題をマークするためのタグも使えるかもしれない。でも、ディスカッションはディスカッションに向いてると思うし、問題トラッカーの機能はメンテイナーや貢献者が使うべきだと思う。この分け方はかなり賢いと思うよ。
> このパターンは、すべての問題が作業可能な状態になっているので、メンテイナーや貢献者が作業する問題を見つけやすくする。どうして「作業可能」タグで簡単に解決できないの？
└
ディスカッションセクションで簡単に解決できないのはどうして？あなたの解決策が他の人のワークフローにとってどうして良いの？オープンソースプロジェクトに自分のやり方を押し付ける権利があると思うのはどうして？
└
一つには、タグを受け取る準備ができるまでに何度もやり取りが必要になるかもしれないけど、今は詳細がいくつかのコメントに分散してるから、すっきりと上にまとまってないんだよね。
└
その解決策は簡単じゃないよ。誰でもイシューにコメントできるようにするには許可が必要で、無関係なコメントや役に立たない意見、さらにはクレームを招くことになるから。分離することで、イシューは実際に問題を修正する開発者だけに制限できる。技術的には、メッセージはメッセージだからね。このアプローチは、メッセージを異なるフォーラムにグループ化するだけだよ。ディスカッションの下にイシュー用のサブフォーラム、機能用のサブフォーラム、他のトピック用のサブフォーラムを作ってもいいし、それぞれのサブフォーラムに許可システムが必要になる。だから、結局はユーザーと開発者のために2つのアクセス領域を作るだけなんだ。それがポイントだよ。結局は好みや嗜好の問題だね。
└
私のデフォルトのビューが「トリアージ」になるのは嫌なんだ。もしGitHubがデフォルトの問題ビューを許可して、タブの問題数にも反映されるなら、考えるかもしれない。でも今はうまくいってない。大規模なプロジェクトで試したけど（20Kスター以上、数百万ダウンロードのプロジェクトがいくつもある）、それに比べてこのシステムは大成功だった。問題もあるけど、方向性としては良くなってる。
└
問題として挙げられた非問題は決してクローズできない。なぜなら、報告した人が「なぜ私の問題を解決せずに閉じたの？」って別の問題を開くから。もしそのユーザーが有効で役に立つ問題も挙げているなら、ただ追放するわけにもいかない。結果的に、問題リストが管理できなくなっちゃうんだよね。
100%同意。誰かのプロジェクトなら、その人がイシューかどうかを決める権限を持ってるよね。大きなプロジェクトになると、エラーメッセージを読まない悪質なユーザーや、単に変な人がいるからね。CVEのインフレみたいな疑わしい目的でAIを使う人もいるし、さらに厄介だよ。
└
失礼で、権利を主張する、攻撃的な人たちを忘れないで。彼らはたくさんいるから。これは本当に素晴らしいアイデアだよ。マインドセットは「何が起こっているのかを理解する」べきで、「これはソフトウェアのせいだ」じゃない。ディスカッションエリアは、周囲の問題を簡単に見つけられる説明や探求の場にもなる。これでメンテナの負担が減るし、デフォルトにすべきだよ。
└
でも、良いイシュー管理ツールなら、その手のものをフィルタリングできるはずだよ。ghosttyがディスカッションをユーザーリクエストやイシューのトリアージに良い方法だと考えるのはちょっと変わってるけど、全然有効な選択肢だと思う。イシューだけを使うのもいいしね。ユーザーがイシューを報告する方法や、どんな情報を含めるべきかを知っておくのが大事だよ。
└
その通りだね。2022年頃、ChatGPTが出た直後にCVEが報告されたことがあった。問題を分析するのに4時間かけて、どこが間違ってるか、背景情報やコードの特定の行にリンクを貼って、何を見落としてるのかを聞いたんだけど、返ってきたのは「肩をすくめるAI」だった。彼らには良かったけどね。
これでいいと思うよ。ここでバリアを設けようとしてるけど、提案された問題の質を上げることが目的みたいだね。これが唯一の目標じゃないかもしれないし、全体的に問題が少なくなることも目指してるかも。でも、そのアプローチにはいくつかの利点と欠点があるから、単なるトレードオフなんだよね。特にオープンソースプロジェクトを運営してると、時間が足りなくて急いで進める必要があるんだ。実際、私のプロジェクトでの問題の議論は気にしないけど、すべてを管理するのにたくさんの時間をかけるのは期待されてないよ。議論か直接的な問題かはあまり重要じゃないけど、何年も解決されないオープンな問題を嫌うプロジェクトオーナーもいるのは知ってる。ここには哲学の違いがあるんだよね。一つのトレードオフは、そんなプロジェクトに関わる可能性が低くなること。議論を始めることはあるけど、基本的に私はかなりカオスで、始めた議論をフォローアップすることはほとんどないんだ。時間がないし、やることが多すぎて、忘れちゃうことも多いからね（ローカルでメモは取ってるけど、そのファイルはどんどん増えていく一方だし！）。
これ、めっちゃ好き。自分のGitHubプロジェクトには、レビューされて承認されるまでオープンな問題を自動でクローズ＆ロックするアクションがあるんだ。それに、スポンサーからの機能リクエストしか考慮しない。ここでの本当の問題は、GitHubにメンテナーだけが問題を作成できるようにする方法がないことだよね。結局、質の低い回避策に頼ることになる。
Pythonの大きなプロジェクトのいくつかがこのアプローチを使ってるんだけど、パワーユーザーとしてはイライラする。明らかにバグだと思うことを見つけるのに、私に負担をかけるような方法で進めなきゃいけない。自分のプロジェクトがそんなに堅牢だと思うのは傲慢だよね。特に「永遠のv0」プロジェクトにおいては。でも、私は超怠け者なんだ。
└
それに、プロジェクトを持ってないのに「明らかにバグだ」と100%知ってるスキルがあると思うのも傲慢だよね。
└
こういう entitlement（権利意識）って、いつも理解するのが難しいんだよね。誰もこれらのプロジェクトを使えって強制してるわけじゃないし。大抵の場合、ユーザーからの軽いバグ報告って、完全に無駄なことが多いんだよね。ユーザーエラーだったり、デバッグするのに十分な詳細が書かれてなかったりするから。つまり、ほとんどがノイズで、さらにノイズを増やしてもあんまり役に立たない。もし貢献したいなら、すでにしっかり定義されたバグに取り組む方がずっといいよ。ソフトウェアには既知のバグがたくさんあるけど、それを直す人が足りてないのが現状なんだ。
私の職場のバグは同じパターンが多い。ある人が壊れてるものや、欠けている機能のせいでできないことを書き上げると、そのバグを説明し、修正や実装に必要な変更点を示す影のタスクが作成される。報告と作業トラッカーが同じ場所にあることに問題は感じたことがないけど、GitHubが「Issues」って名前を付けたのはあまり良い名前じゃなかったかもしれないね。
GitHubにディスカッション機能があるなんて知らなかった！これ、いいね。