なんでそう言うの？Curl（世界で最も使われているオープンソースソフトウェアの一つだと思うけど）は、現在5つのオープンな問題があるよ。 https://github.com/curl/curl/issues

実際の違いって何なんだろう？メンテナとして、本当に問題があるのかどうかを見分けたいなら、結局は全部読まなきゃいけない（トリアージ）。それが時間がかかる理由だよね。ディスカッションをイシューに変えるのが、逆にするよりも楽だとは思えない。どっちもクリック一つだし。GitHubのイシューとディスカッションは、ほぼ同じ機能に見える（UIもほぼ同じで名前が違うだけ）。唯一の利点は、ディスカッションにはトップレベルのアップボート数があることかな。

「もしディスカッションから手動でイシューを作るよりも、イシューを閉じるのに時間をかけるなら、計算が合うよ。全てのイシューを無視して、2週間後に古くなったから閉じるってやり方なら、もっと計算が良くなる！」これが冗談だったらいいのに、そうじゃないんだよね。

それを聞くのは残念だね。メモリリークの問題でGhosttyを諦めざるを得なかったよ。確かに8GBのシステムだったけど、週に数回ターミナルを動かすのには十分なはずなんだ。Footは安定してるけど、Ghosttyの便利機能がないのがちょっと残念。

作者は最初のリンクで、報告されたのは2回だけだと言ってるけど、それはおそらく後の2つのリンク（2つのディスカッション）を指してるんじゃないかな。君の2つ目のリンクは、Xのユーザーが炎上を狙ってるように見えるけど、他の返信は私には隠されてる。

逆のことだと思うけどね。ユーザーの不満はすべてディスカッションから始まるんだ。そこから実行可能なバグ報告が出たら、トラッカーに行く。それが問題リストとして機能するんだ。多くのディスカッションはこのようには終わらないけど、アドバイスや参考を提供することでユーザーの問題を解決することもあるよね。確かに、問題トラッカーでもディスカッションができるし、作業可能な問題をマークするためのタグも使えるかもしれない。でも、ディスカッションはディスカッションに向いてると思うし、問題トラッカーの機能はメンテイナーや貢献者が使うべきだと思う。この分け方はかなり賢いと思うよ。

ディスカッションセクションで簡単に解決できないのはどうして？あなたの解決策が他の人のワークフローにとってどうして良いの？オープンソースプロジェクトに自分のやり方を押し付ける権利があると思うのはどうして？

一つには、タグを受け取る準備ができるまでに何度もやり取りが必要になるかもしれないけど、今は詳細がいくつかのコメントに分散してるから、すっきりと上にまとまってないんだよね。

その解決策は簡単じゃないよ。誰でもイシューにコメントできるようにするには許可が必要で、無関係なコメントや役に立たない意見、さらにはクレームを招くことになるから。分離することで、イシューは実際に問題を修正する開発者だけに制限できる。技術的には、メッセージはメッセージだからね。このアプローチは、メッセージを異なるフォーラムにグループ化するだけだよ。ディスカッションの下にイシュー用のサブフォーラム、機能用のサブフォーラム、他のトピック用のサブフォーラムを作ってもいいし、それぞれのサブフォーラムに許可システムが必要になる。だから、結局はユーザーと開発者のために2つのアクセス領域を作るだけなんだ。それがポイントだよ。結局は好みや嗜好の問題だね。

私のデフォルトのビューが「トリアージ」になるのは嫌なんだ。もしGitHubがデフォルトの問題ビューを許可して、タブの問題数にも反映されるなら、考えるかもしれない。でも今はうまくいってない。大規模なプロジェクトで試したけど（20Kスター以上、数百万ダウンロードのプロジェクトがいくつもある）、それに比べてこのシステムは大成功だった。問題もあるけど、方向性としては良くなってる。

問題として挙げられた非問題は決してクローズできない。なぜなら、報告した人が「なぜ私の問題を解決せずに閉じたの？」って別の問題を開くから。もしそのユーザーが有効で役に立つ問題も挙げているなら、ただ追放するわけにもいかない。結果的に、問題リストが管理できなくなっちゃうんだよね。

失礼で、権利を主張する、攻撃的な人たちを忘れないで。彼らはたくさんいるから。これは本当に素晴らしいアイデアだよ。マインドセットは「何が起こっているのかを理解する」べきで、「これはソフトウェアのせいだ」じゃない。ディスカッションエリアは、周囲の問題を簡単に見つけられる説明や探求の場にもなる。これでメンテナの負担が減るし、デフォルトにすべきだよ。

でも、良いイシュー管理ツールなら、その手のものをフィルタリングできるはずだよ。ghosttyがディスカッションをユーザーリクエストやイシューのトリアージに良い方法だと考えるのはちょっと変わってるけど、全然有効な選択肢だと思う。イシューだけを使うのもいいしね。ユーザーがイシューを報告する方法や、どんな情報を含めるべきかを知っておくのが大事だよ。

その通りだね。2022年頃、ChatGPTが出た直後にCVEが報告されたことがあった。問題を分析するのに4時間かけて、どこが間違ってるか、背景情報やコードの特定の行にリンクを貼って、何を見落としてるのかを聞いたんだけど、返ってきたのは「肩をすくめるAI」だった。彼らには良かったけどね。

それに、プロジェクトを持ってないのに「明らかにバグだ」と100%知ってるスキルがあると思うのも傲慢だよね。

こういう entitlement（権利意識）って、いつも理解するのが難しいんだよね。誰もこれらのプロジェクトを使えって強制してるわけじゃないし。大抵の場合、ユーザーからの軽いバグ報告って、完全に無駄なことが多いんだよね。ユーザーエラーだったり、デバッグするのに十分な詳細が書かれてなかったりするから。つまり、ほとんどがノイズで、さらにノイズを増やしてもあんまり役に立たない。もし貢献したいなら、すでにしっかり定義されたバグに取り組む方がずっといいよ。ソフトウェアには既知のバグがたくさんあるけど、それを直す人が足りてないのが現状なんだ。