mbauman
2021 年 8 月 11 日午後 3:08
1
スローモードの意図は非常に気に入っていますが、当 Discourse 上で炎上を引き起こす最も一般的な要因には完全には対応できていません。
「熱狂的」な人が現れます。それは新規ユーザーであることもあれば、別のコミュニティから来た人であることもあります。そして、不満のリストを提示します。
多くの既存メンバーが、元の投稿者に対して、あるいは彼らを相手にして反応します。その動機は様々ですが、「インターネット上で誰かが間違っている」と思っている という症候群が上位を占めています。
元の投稿者は、全員に対して、あるいは全員を相手にして反応したくなります。
最良の議論であっても、状況は急速にエスカレートします。
スローモードはここで役立ちません。なぜなら、これは「多対一」の問題だからです。多くの人が応答できる一方で、元の投稿者のクールダウンタイマーが進行している間に、彼らが感じる制限の負担は最も大きくなります。そして、彼らが反応できるのはたった 1 つの投稿だけなのです。
このような状況において、私のツールボックスに欲しいツールは、トピックの「バンプ」を遅くすることです。デフォルトのリスト（最新とトップの両方）は、これらの「熱狂的」なトピックを優先します。バンプを 12 時間に 1 回などに制限できるようにしたいです。そうすれば、完全にリストから消えるわけではありませんが、大きく目立たなくすることで、議論への新規参加者の数を制限できるかもしれません（積極的に探して参加する人は別ですが、それはそれで問題ありません）。
「いいね！」 16
やる気のあるユーザーなら、単一の返信で多くの他の投稿者を巻き込むことも可能ですよね？……それでもスローモードでは可能です。
ただし、スローモードでも「バンプを減らす」機能があれば便利だとは私も思います。
「いいね！」 2
mbauman
2021 年 8 月 11 日午後 5:46
3
その通りです。しかし、複数のメッセージに返信するそのような巨大な投稿は、トピックの管理をさらに困難にします。分割が不可能になるだけでなく、投稿者がさらに攻撃的になる傾向を強めたり、少なくとも大量のテキストの壁という事実だけで、挑発的な印象を与えたりするのです。
「いいね！」 5
実は、これは Julia Discourse （非常に活発な有料ホストインスタンス）でも見られた、スローモードの意図しない副作用の一例です。スローモードが有効になると、新規投稿を書く代わりに、既存の投稿を編集する人が現れます。問題のあるユーザーを TL0 に設定した場合も同様の問題が起きます。新しい投稿はできても過去の投稿の編集は可能なので、彼らはその機能を利用します。特に、炎上を招くような内容に人々が返信した後、そのユーザーが内容を編集すると、返信が文脈から外れて見えるようになるため、状況はさらに悪化します。
とはいえ、@mbauman さんの提案には完全に賛成です。ホットトピックが頻繁にトップに押し上げられるのを防ぐ機能があれば、議論を落ち着かせるのに非常に役立つでしょう。
「いいね！」 3
RGJ
2021 年 10 月 14 日午前 4:30
5
ホットトピックが持ち上げられるのを防ぐだけでなく、通知 を遅らせるという手もあります。これにより、複数のユーザーに返信したり言及したりする際の問題が解消されます。
「いいね！」 4
sam
2021 年 10 月 14 日午前 7:23
6
今すぐ使える裏技として、このようなトピックを非公開（リスト外）に設定する方法があります。自動で再公開するタイマー機能の追加も計画していますが、手動で対応することも可能です。
「トピックを沈める」機能は過去に話題になったことがあり、私たちも検討してきたアイデアです。
「いいね！」 5
提案されている内容がよく理解できません。これがどのように機能するのか、ユーザーには何が見え、スタッフメンバーには何が見えるのか、UIモックアップを見せていただけますか？
だからこそ、スローモードではデフォルトで編集が制限されています。コミュニティがそのようなことをしないと信頼できる場合は、編集制限をオフにすることができます。
そして、@samが言ったことを検討してください 。トピックをリストから外してください。 新しいツールを提案する前に、ツールキット内の既存のツールを最大限に活用してください。
mbauman
2022 年 1 月 18 日午後 3:10
8
主なアイデアは非常にシンプルです。管理者のトピックメニューにある「
実装方法についてはあまりこだわりはありません。ステートフル（トピックの更新時間をBumpした最後の投稿を追跡し、新しい投稿の時間がX時間後より後である場合にのみ更新する）でも、ステートレス（トピックの更新時間を、Unixエポックまたは最初の投稿からX時間の倍数のフロア値に常に設定する）でも構いません。あるいは、何か別の方法でも良いです。
ユーザーに表示される内容については、必ずしも伝える必要はないかもしれませんが、「このトピックはトピックリストの一番上にX時間ごとに1回しか表示されません」というシンプルな「リスト外」の投稿アイテムとして表示される可能性があります。
他のツールとしては、スレッドのリスト解除を時々使用しますが、これはすべて戦闘的な新規ユーザーに関するものです。多くの場合、検閲の兆候に非常に腹を立てるようなタイプの人々です。そして、私は本当に物事を検閲/非表示/削除したくありません。全体的な目的は、それ自体でより多くの不満を引き起こす可能性が低いと思われるソフトな介入であり、それでも温度を少し低く保つのに役立つことを願っています。
これは、Hacker Newsがコメント数が投票数を大幅に上回るトピックをペナルティする仕組みに多少触発されています。
「いいね！」 2
@sam @eviltrout 、この件についてどう思われますか？ここに時間を表す整数を入れることができます。0は「決して引き上げられないようにする」、1〜6000は「{x}分ごとに1回だけ引き上げを許可する」といった意味になります。
「いいね！」 1
eviltrout
2022 年 1 月 18 日午後 5:28
10
面白いアイデアですね。バンプに対するデバウンスのようなものです。
パワーツールのように見えますが、役立つと思います。追加するのは簡単なことではないと思います。おそらく中程度の労力が必要でしょう。
「いいね！」 1
saquetim
2022 年 1 月 18 日午後 7:17
11
最初の段階でモデレーションによってトピックが過熱するのを防ぐことは、特にユーザーが多い場合に、いくつかのシナリオで役立つと思います。
トピックがすでに過熱しており、議論が自己維持されている場合、スレッド内のインタラクションからユーザーが受け取る通知がそれを継続させる可能性が高いため、スローモードの方がうまく機能するでしょう。
ソースコードを確認したところ、モデルを変更する以外に、bypass_bump? を変更するだけでトピックが再び表示されるのを防ぐことができるでしょうか？
end
def bump_topic
return if bypass_bump? || !is_last_post?
@topic.update_column(:bumped_at, Time.now)
TopicTrackingState.publish_muted(@topic)
TopicTrackingState.publish_unmuted(@topic)
TopicTrackingState.publish_latest(@topic)
end
def bypass_bump?
!@post_successfully_saved ||
@topic_changes.errored? ||
@opts[:bypass_bump] == true ||
@post.whisper? ||
only_hidden_tags_changed?
end
def only_hidden_tags_changed?
return false if (hidden_tag_names = DiscourseTagging.hidden_tag_names).blank?
たとえば、Topic に min_seconds_between_bumps のようなフィールドを追加し、bypass_bump? に別の条件を追加する必要があるかもしれません。
def bypass_bump?
!@post_successfully_saved ||
@topic_changes.errored? ||
@opts[:bypass_bump] == true ||
@post.whisper? ||
only_hidden_tags_changed? ||
@topic.min_seconds_between_bumps == 0 ||
(@topic.min_seconds_between_bumps > 0 &&
(Time.now - @topic.bumped_at) / 60 < @topic.min_seconds_between_bumps)
end
トピックがまったく表示されないことを示す 0 の値については、確信がありません。ユーザーを混乱させる可能性があります。このように実装する場合、ゼロを直接ユーザーに表示しない方が、UXの観点からは良いと思います。
「いいね！」 3
もし私の解釈が正しければ、返信が投稿された時点でスレッドを上げるかどうかの判断が行われますが、スレッド上げ禁止期間後に後続の返信が投稿されなかった場合、そのスレッドは決してスレッド上げされなくなります。
これは望ましい動作でしょうか、それとも期間中に返信があった場合、スレッドは常に期間終了時にスレッド上げされるべきでしょうか？常にスレッド上げされるべき場合、それは「現在」にスレッド上げされるべきか、それとも最新の返信時刻にスレッド上げされるべきでしょうか？
「いいね！」 2
saquetim
2022 年 1 月 18 日午後 8:07
13
はい、このアプローチでは、決定は返信が投稿された時に行われ、後続の返信がなければトピックが再びバンプされることはありません。Discourseのソースコードの専門家ではないので確信はありませんが、これが実装する上で簡単な方法になるでしょう。
クールダウン期間後にバンプするという他の可能な動作は、@eviltroutが言ったように 、より多くの作業が必要になるでしょう。なぜなら、アプリケーションが次に期待されるバンプを保存し、保留中のバンプを定期的に実行するためのスケジューラまたはsidekiqジョブのようなものが必要になるからです。
どちらのアプローチも有効であり、これが実装されるとしても、どちらが選択されるかはわかりません。
個人的には、後続の返信がない場合に問題のあるトピックが二度とバンプされなくても気にしません。しかし、それはあくまで私の意見です。
「いいね！」 2
私の考えでは、最もシンプルなロジックは次のとおりです。
トピックには「{x} 分ごとに 1 回しか BUMP できません」という設定があり、分数は調整可能な設定で、ゼロ（デフォルトでは、返信の数だけ BUMP できます）から約 10,000（週に 1 回しか BUMP できません）まであります。誰かが 60 分を入力したと仮定すると、トピックは最大 60 分ごとに 1 回しか BUMP できません。
返信が投稿されたとき に、最後の BUMP 日付を確認します。
はい、これはシンプルで実用的なようです。次のリリースに追加しましょうか @sam @eviltrout ？
「いいね！」 6
-1（無期限に増やすことができない）も価値があるでしょうか？私はそうではない方に傾いています。そのようなトピックを後で見つけるのは難しいでしょう（追加の作業なしでは）、そして管理者がトピックを絶対に増やしたくないのであれば、単に閉じる方が理にかなっているでしょう。
実際、最大時間設定は管理者ページで設定可能な設定であるべきだと思います。max_slowbump_timeのようなものです。
また、ついでに。カテゴリレベルでスローバンプを適用することも可能でしょうか？
Keno
2025 年 11 月 11 日午後 2:48
17
このような機能は実装されましたか？ 元々@mbaumanがリクエストしたスレッドがあり、この機能が現在利用可能であれば、それを使用できると素晴らしいです。
Bump Dateをリセット」項目の隣に、「トピックのBumpを制限…」のような名前で配置します。すると、時間間隔を入力するモーダルボックスが表示されます。「このトピックが最新表示やその他のカテゴリ表示の一番上に表示される頻度を、X時間ごとに最大1回に制限します」といったテキストが表示され、デフォルトは8時間程度になります。