なぜGitやDebianのようないくつかの大きなプロジェクトでは、メーリングリストのみを使用し、問題トラッカーを使用しないのですか？

まともなサイズのプロジェクトのバグトラッカーは、私にとっては簡単なことのように思えます。問題が衝突したり混同したりすることなく、数百または数千の問題を非常に簡単に整理できます。

そのため、Gitのように、メンテナンスと開発を調整する主な方法としてメーリングリストを使用するいくつかの非常に大きなプロジェクトを見ると、少し圧倒されます。例：

• Git-コミュニティページ：

  ...バグレポートはこのメーリングリストに送信する必要があります。

• WikipediaごとのDebianバグ追跡システム：

  ...そのユニークな機能は、バグレポートを編集するためのウェブインターフェースの形式がないことです-すべての変更は電子メールを通して行われます。

最新のバグトラッカーの多くは、電子メール（見ているバグや自分に割り当てられているバグに関するコメントや通知を受け取ることができます）やバージョン管理システム（問題を解決するなどのマークを付けることができます）と非常によく統合されています。）。この多くは、メーリングリストを使用して手動で行う必要があり、興味のないバグに関する大量の電子メールを受け取ることになります。

それでは、Webベースのバグトラッカーに対するメーリングリストの主な利点は何ですか？一部の大きなプロジェクトでメーリングリストのみが使用されるのはなぜですか？

観察する好みは、GNU Coding Standardsで明確に述べられている推奨の自然な結果のように見えます。以下の引用文にあるように、電子メールでバグを報告することをお勧めします（観察に直接対処する部分を太字で示しています）。

4.7.2 --help

標準--helpオプションは、プログラムを起動する方法に関する簡単なドキュメントを標準出力に出力し、正常に終了する必要があります。他のオプションと引数は、これが見られたら無視されるべきであり、プログラムは通常の機能を実行すべきではありません。

‘--help’オプションの出力の終わり近くに、バグレポート用のメールアドレス、パッケージのホームページ（通常‘http://www.gnu.org/software/pkg’、GNUプログラムを使用するための一般的なページ）を示す行を入力してください。形式は次のようになります。

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

他の適切なメーリングリストやWebページに言及してもかまいません。

同様に、上記の好みは、電子通信の形式としての電子メールの普遍的な受け入れを反映しています。--help上記のようなメッセージを読んでいるユーザーは、バグを見つけた場合の対処方法を簡単に理解できるはずです-郵送は簡単です。

課題トラッカーはあるかもしれない（と私は考えている）プロジェクトで働く開発者のためのより良い、より広い聴衆のためには、特に考慮に多種多様と異なるとの違い取って、提示し、それを使用する方法を説明するのは難しいだろう問題追跡システムを。

1つのプロジェクトはBugzillaを使用でき、別のプロジェクトはJIRAに固執し、3つ目はGNATSなどに固執します。など。

Report bugs to: mailing-address

上記の注意は、プロジェクトが課題トラッカーを内部で使用するべきでないことを意味しません。関連する質問に対する優れた回答で説明されているように、

あなたのバグトラッカーはあなたの便宜のためであり、あなたの顧客のためではありません。電話やメールの問題を自分で入力してわざわざ入力できない場合、どのように感じますか？

問題を入力し、クライアントに手動で割り当てることができる必要があります...

特にGitには、単純な歴史的理由があります。GitはLinuxハッカーのためにLinuxハッカーによって開始され、Linux自体と同じ開発モデルとツールを使用します。ただし、LinuxはWWWよりも古いため、Linuxが起動されたとき、 Web が存在しなかったため、Webベースの問題トラッカーはありませんでした。

その結果、Linuxコミュニティは、電子メールでバグレポートとコードレビューを処理するための非常に効率的なツールとワークフローを開発しました。Gitプロジェクトを開始したときに、すべての作業を破棄してゼロから開始する理由はありませんでした。

Gitの場合：

メーリングリストには、ある種のバグトラッカーの使用を提案する議論がいくつかあります。これらのイニシアチブはすべてくすんだように見えるので、Gitがバグトラッカーを使用しない理由はおそらく、ほとんどの貢献者がバグトラッカーを役に立たないためだと思われます。

ではメーリングリストに投稿し、彼はバグトラッカーは非常に便利ではないと感じる理由を、Junio C浜野（Gitリポジトリのメンテナ）がまとめました。投稿全体を含めたくはありません（かなり長いです）が、要約すると次のようになります。

• 解決された問題に関する情報だけを探している場合は、バグトラッカーを検索するのと同じように、リストアーカイブを検索できます。
• あなたが本物のバグを報告し、人々がそれの世話をしたい場合、リストもうまく機能します。
• 誰も問題に取り組むことに興味がないなら、それはバグトラッカーでさえ、ひびを通って落ちるでしょう。
• バグトラッカーは、メンテナンスする必要があるもう1つのシステムであり、定期的に新しいバグをチェックし、修正されたバグをクローズしているなどです。

Debianはバグトラッカーを使用します。デフォルトのインターフェースは電子メールです。そして便利です。現在のDebianプロジェクトリーダーであるLucas Nussbaum は数日前に投稿しました：

debbugsは、Debianバグ追跡システム（BTS）の背後にあるソフトウェアです。GNUプロジェクトでも使用されます。古いスタイルとして認識されることが多いにもかかわらず、パッケージの各バージョンおよびブランチのバグのステータスの追跡などのいくつかのユニークな機能、または電子メールを介してすべての対話を実行する機能により、作業が非常に簡単になります。オフラインまたは接続が不十分な環境。

最後の部分はここでのキラー機能です-飛行機から降りるまで、それらのレポートをローカルのメールキューに入れるだけです！

• 9歳児を締め出します。
• フォーラムごとに個別のアカウントを作成する必要はありません。
• [マイナー]さまざまなメーリングリストで一貫したユーザーエクスペリエンスを提供し、新しいリストを購読する際の学習曲線はゼロです。
• オフラインで動作します。インターネットに接続して一連のメールをダウンロードし、ハイキングに行き、母なる自然を楽しみながら返信を書き、後で送信することができます。
• GPGを介したメールの暗号化および/または署名を許可します。
• 分散型-フォーラムがクラッシュした場合、コピーが残っているだけでなく、改ざんに対する耐性もあります。邪悪なモデレーター/ハッカーは、あなたが言ったことを簡単に改ざんすることはできません。履歴を元に戻すことはできません。
• メールクライアントのフィルター、フォルダー、およびすべての高度な組織機能を許可します。
• 「プッシュ通知」-メールクライアントを開いたままにして、新しい返信の通知を受け取ることができます。
• それらすべてを支配する1つの場所-異なるサイト間をジャンプする必要はありません。
• Webに関連するすべてのセキュリティ脆弱性（html / javascript / injectionsなど）に対する耐性
• 膨張なし-バッジ、派手な移動署名、広告、ウェブビーコン、javascript膨張はありません。それはすべてシンプルで、要点-議論です。
• LAMPセットアップよりもサーバーの負担が少ない。

思い浮かぶメーリングリストの欠点の1つは、フォーラムがカテゴリとサブカテゴリに分かれているのに対し、メーリングリストはそうではないことです。これは、メーリングリストを複数のメーリングリストに分割することでエミュレートでき、ユーザーは適切なフィルターを使用して各メッセージを対応するフォルダー（各フォルダーがカテゴリー）に入れることができます。Webフォーラムでは、これは自動です。