@Stephen、この件についてご議論いただきありがとうございます。
これはコミュニティ固有の課題だと思います
おっしゃる通りです。そのため、既存の「重複タイトルを許可しない」設定を再利用するか、新しいチェックボックスを追加する形で、設定で制御できるようにすることを提案します。
数が少なく、より長いトピックを持つことにどんな価値があるのでしょうか？
背景として、当社の Discourse サイト には「Notifications」というカテゴリがあり、その各サブカテゴリには、特定のイベント（テストの失敗、新しい Issue の作成、新しい Stack Overflow の質問、ディスカッションサイトでの当プロジェクトへの言及など）が発生した際にスクリプトから送信されるメールが配信されます。これらのカテゴリは、コミュニティメンバーが関心のある特定の種類のイベントを追跡し、議論できるように設計されています。
場合によっては、スクリプトによって生成されるメールの件名は設計上、予測可能で決定的なものになります。例えば「linux64 testing」などです。例えば、8月15日に linux64 テストで新しい失敗が発生するとメールが送信されます。8月16日にさらに失敗が追加されれば、同じ件名で2通目のメールが生成されます。その後、8月17日にすべての失敗が解消されれば、その旨を示す同じ件名の3通目のメールが生成されます。さらに8月31日に新しい失敗が発生すれば4通目、解消されれば5通目のメールが同じ件名で生成されます。
現在のサイト動作では、これらのメールのそれぞれが「linux64 testing」という全く新しいトピックを生成し、それらの間にリンクや関連性が存在しないため、人間がイベントを関連付けたり、失敗に関するフォローアップ議論にどのトピックを使用すべきか判断したりすることが困難です。私たちが望むのは、これら5通のメール（およびそれらに関連するユーザーの議論）がすべて単一のトピック内の投稿として表示されることです。そうすれば、開発者は特定の構成におけるすべてのテスト失敗を、時系列で整理された単一のトピック内で確認できます。
現在の Discourse の動作のもう一つの影響として、該当のカテゴリやトピックのメール通知を受け取っている人は、受信トレイに「linux64 testing」という名前の無関係なスレッドが5本表示されることになります。Discourse がこれらを単一のトピックにマージすれば、その人はメールリーダー内で「linux64 testing」に関連するすべての投稿が単一のスレッドとして表示されるため、はるかにナビゲーションしやすく、従来の会話に近い形になります。
私たちは毎晩数十種類のテスト構成を実行しており、失敗が発生するたびにそれぞれ固有の件名が付けられます。そのため、現在の状況では、メールごとに独立した浅いトピックが時系列に散在し、広がりすぎていてナビゲーションが難しい状態になっています。理想的には、「Notifications.Tests」カテゴリに、各構成ごとの単一のトピックが表示され、その固有の件名によって決定された時系列で、その構成に関する人間またはスクリプトによって生成されたすべての投稿が格納されることです。
[このテストカテゴリは現在、当サイトでは公開されていませんが、@Stephen 様もしその様子をご覧になり、実際に不便さを感じてみたい場合は、一時的に読み取り権限を付与することも可能です。お気軽にお知らせください。]
meta のようなコミュニティの場合、「mailgun の設定に関する問題」でメールを送信したユーザーは、問題を解決してから数ヶ月、数年経っても更新通知を受け取り続けることになります。
この選択が、meta のように大規模で長期的なコミュニティには適さないことは同意します。そのようなコミュニティでは、メールから生成された投稿を単一のトピックに集約する必要がないためです。したがって、そのような機能が存在しても、おそらくオプトインはしないでしょう。（また、時間とともに、私たちのようなサイトも同様の理由で不要になるかもしれません。その場合、理想的なのはカテゴリごとにチェックボックスを適用できるようにすることですが、現時点ではサイト全体の単一設定で十分だと考えており、あまり多くを求めたくなかったので、この提案に至りました）。
とはいえ、私たちのようなサイトがそのような機能にオプトインしたとしても、「mailgun の設定に関する問題」というトピックの投稿者が、同じ件名を共有するその後の投稿に困惑したとしても、他の誰かが同じ件名を使用した場合（または Web インターフェースを通じてそのトピックに別の投稿を追加した場合）に更新を受け取り続けるのを避けるために、そのトピックを購読解除することは可能だと考えられます。
[ただし、ほとんどの人間ユーザーは Web サイトを通じて投稿するため、この機能の影響は人間が生成した投稿よりも、スクリプトが生成した投稿に対してより大きくなると予想されます]