BradCray
2020 年 9 月 9 日午前 3:59
1
現在、同じ件名のメールが特定の Discourse カテゴリに 2 通送信されると、それぞれのメールがその件名をタイトルとして持つ独自のトピックを作成します。これにより、「同じタイトルを持つトピックを許可する…」という設定オプションが選択されているかどうかに関わらず、同じタイトルを持つ複数のトピックが作成されてしまい、結果として同じタイトルを持つトピックが多数存在することになります。
ここで要望しているのは、件名が一致する場合に、メールから生成された投稿を既存のトピックに自動的にマージすることです（「カテゴリが異なる場合に同じタイトルを持つトピックを許可する」オプションがオフの場合、または「メールで送信された投稿を件名がトピックのタイトルと一致する場合に既存のトピックにマージする」という新しいオプションを追加することで実現できます）。これにより、カテゴリ内で重複するタイトルを避けつつ、同じ件名を持つ複数のメールを単一のトピックに集約できるという利点があります（意図的であれ偶然であれ）。
実際には、当サイトでは「特定のテスト設定が失敗した」や「誰かが Reddit で xyz について言及した」など、単一のトピックに関連する投稿を生成するスクリプトを使用しています。このような件名を持つすべてのメールを、メールごとに同じタイトルを持つ新しいトピックを作成するのではなく、単一のトピックにグループ化することが理想的です。また、メール通知への返信を行わずとも、特定のトピックに新しい投稿を追加できるようになります（何らかの理由で Web インターフェースではなくメールでの投稿が必要な場合など）。
人間が誤って、既存のトピックと偶然に件名が一致するメールを送信してしまうという潜在的な欠点の可能性は低いと考えられます。なぜなら、件名が既存のトピックのタイトルと一致する場合は、内容の類似性が原因であることが多く、重複したタイトルを持つ新しいトピックを作成するのではなく、既存のトピックを拡張することに大きな問題はないと思われるからです。さらに、サイト管理者が現在の動作（各新しいメールが新しいトピックを作成する）を望む場合は、「同じタイトルを持つトピックを許可する」チェックボックスをオンにすることも可能です。
この機能は、当社の Discourse サイトにとって非常に有用であり、他のサイトにとっても同様である可能性が高いと考えています。ご検討いただき、また Discourse に明らかに投入された素晴らしいエンジニアリングに感謝申し上げます。
Stephen
2020 年 9 月 9 日午前 5:07
2
これはコミュニティ固有の問題であり、ご自身がおっしゃる通り、意図しない衝突は発生します。少数の非常に長いトピックが存在することにはどのような価値があるのでしょうか？
メタのようなコミュニティの場合、「Mailgun の設定に関する問題」という件名でメールを送信したユーザーは、問題を解決してから数ヶ月、あるいは数年経っても更新通知を受け取り続けることになります。これは現実的ではないでしょう。
目標は重複したタイトルを避けることです。現在の設定では、サイト内でトピックを作成する際にユーザーにフィードバックを与えることができるため、この制約が適用されます。しかし、メールで送信してくるユーザーの場合、そのような機会がないため、この設定は尊重されません。
BradCray
2020 年 9 月 9 日午後 4:52
3
@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 サイトを通じて投稿するため、この機能の影響は人間が生成した投稿よりも、スクリプトが生成した投稿に対してより大きくなると予想されます]