# より穏やかなスローモード：スローバンプ？
**URL:** https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080
**Category:** Feature
**Tags:** slow-mode
**Created:** [2021 年 8 月 11 日午後 3:08 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080 "2021-08-11T15:08:56Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@mbauman](https://meta.discourse.org/u/mbauman)
#### Post date: [2021 年 8 月 11 日午後 3:08 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/1 "2021-08-11T15:08:57Z")
スローモードの意図は非常に気に入っていますが、当 Discourse 上で炎上を引き起こす最も一般的な要因には完全には対応できていません。
- 「熱狂的」な人が現れます。それは新規ユーザーであることもあれば、別のコミュニティから来た人であることもあります。そして、不満のリストを提示します。
- 多くの既存メンバーが、元の投稿者に対して、あるいは彼らを相手にして反応します。その動機は様々ですが、[「インターネット上で誰かが間違っている」と思っている](https://xkcd.com/386/) という症候群が上位を占めています。
- 元の投稿者は、全員に対して、あるいは全員を相手にして反応したくなります。
- 最良の議論であっても、状況は急速にエスカレートします。
スローモードはここで役立ちません。なぜなら、これは「多対一」の問題だからです。多くの人が応答できる一方で、元の投稿者のクールダウンタイマーが進行している間に、彼らが感じる制限の負担は最も大きくなります。そして、彼らが反応できるのはたった 1 つの投稿だけなのです。
このような状況において、私のツールボックスに欲しいツールは、トピックの「バンプ」を遅くすることです。デフォルトのリスト（最新とトップの両方）は、これらの「熱狂的」なトピックを優先します。バンプを 12 時間に 1 回などに制限できるようにしたいです。そうすれば、完全にリストから消えるわけではありませんが、大きく目立たなくすることで、議論への新規参加者の数を制限できるかもしれません（積極的に探して参加する人は別ですが、それはそれで問題ありません）。
---
### Author:  [@craigconstantine](https://meta.discourse.org/u/craigconstantine)
#### Post date: [2021 年 8 月 11 日午後 5:40 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/2 "2021-08-11T17:40:10Z")
やる気のあるユーザーなら、単一の返信で多くの他の投稿者を巻き込むことも可能ですよね？……それでもスローモードでは可能です。
ただし、スローモードでも「バンプを減らす」機能があれば便利だとは私も思います。 🙂
---
### Author:  [@mbauman](https://meta.discourse.org/u/mbauman)
#### Post date: [2021 年 8 月 11 日午後 5:46 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/3 "2021-08-11T17:46:40Z")
> [@craigconstantine](#):
>
> やる気のあるユーザーなら、単一の返信で多くの他の投稿者にも対応できるはずです。……それでもスローモードでは可能でしょう。
その通りです。しかし、複数のメッセージに返信するそのような巨大な投稿は、トピックの管理をさらに困難にします。分割が不可能になるだけでなく、投稿者がさらに攻撃的になる傾向を強めたり、少なくとも大量のテキストの壁という事実だけで、挑発的な印象を与えたりするのです。
---
### Author:  [@StefanKarpinski](https://meta.discourse.org/u/StefanKarpinski)
#### Post date: [2021 年 10 月 13 日午後 8:59 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/4 "2021-10-13T20:59:52Z")
実は、これは [Julia Discourse](https://discourse.julialang.org)（非常に活発な有料ホストインスタンス）でも見られた、スローモードの意図しない副作用の一例です。スローモードが有効になると、新規投稿を書く代わりに、既存の投稿を編集する人が現れます。問題のあるユーザーを TL0 に設定した場合も同様の問題が起きます。新しい投稿はできても過去の投稿の編集は可能なので、彼らはその機能を利用します。特に、炎上を招くような内容に人々が返信した後、そのユーザーが内容を編集すると、返信が文脈から外れて見えるようになるため、状況はさらに悪化します。
とはいえ、@mbauman さんの提案には完全に賛成です。ホットトピックが頻繁にトップに押し上げられるのを防ぐ機能があれば、議論を落ち着かせるのに非常に役立つでしょう。
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [2021 年 10 月 14 日午前 4:30 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/5 "2021-10-14T04:30:51Z")
ホットトピックが持ち上げられるのを防ぐだけでなく、_通知_を遅らせるという手もあります。これにより、複数のユーザーに返信したり言及したりする際の問題が解消されます。
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2021 年 10 月 14 日午前 7:23 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/6 "2021-10-14T07:23:01Z")
今すぐ使える裏技として、このようなトピックを非公開（リスト外）に設定する方法があります。自動で再公開するタイマー機能の追加も計画していますが、手動で対応することも可能です。
「トピックを沈める」機能は過去に話題になったことがあり、私たちも検討してきたアイデアです。
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2022 年 1 月 17 日午後 8:03 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/7 "2022-01-17T20:03:59Z")
> [@mbauman](#):
>
> このような状況でツールボックスにあればいいなと思う機能の一つに、トピックの更新頻度を遅くする機能があります。デフォルトのリスト（最新およびトップ）では、これらの「ホットな」トピックが優先されます。更新を12時間ごとに1回に制限するなど、何らかの制限を設けたいと考えています。そうすれば、完全にリストから外れるわけではありませんが、大幅に注目度が下がり、議論への新規参加者の数を制限するのに役立つでしょう（彼らが積極的に探し出さない限りは、それはそれで問題ありません）。
提案されている内容がよく理解できません。これがどのように機能するのか、ユーザーには何が見え、スタッフメンバーには何が見えるのか、UIモックアップを見せていただけますか？
> [@StefanKarpinski](#):
>
> スローモードがオンになり、一部の人が新しい投稿を書く代わりに既存の投稿を編集し始めます。
だからこそ、スローモードではデフォルトで編集が制限されています。コミュニティがそのようなことをしないと信頼できる場合は、編集制限をオフにすることができます。
そして、@samが言ったことを検討してください。 **トピックをリストから外してください。** 新しいツールを提案する前に、ツールキット内の既存のツールを **最大限に活用してください。**
---
### Author:  [@mbauman](https://meta.discourse.org/u/mbauman)
#### Post date: [2022 年 1 月 18 日午後 3:10 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/8 "2022-01-18T15:10:03Z")
主なアイデアは非常にシンプルです。管理者のトピックメニューにある「⚓ Bump Dateをリセット」項目の隣に、「トピックのBumpを制限…」のような名前で配置します。すると、時間間隔を入力するモーダルボックスが表示されます。「このトピックが最新表示やその他のカテゴリ表示の一番上に表示される頻度を、X時間ごとに最大1回に制限します」といったテキストが表示され、デフォルトは8時間程度になります。
実装方法についてはあまりこだわりはありません。ステートフル（トピックの更新時間をBumpした最後の投稿を追跡し、新しい投稿の時間がX時間後より後である場合にのみ更新する）でも、ステートレス（トピックの更新時間を、Unixエポックまたは最初の投稿からX時間の倍数のフロア値に常に設定する）でも構いません。あるいは、何か別の方法でも良いです。
ユーザーに表示される内容については、必ずしも伝える必要はないかもしれませんが、「このトピックはトピックリストの一番上にX時間ごとに1回しか表示されません」というシンプルな「リスト外」の投稿アイテムとして表示される可能性があります。
* * *
他のツールとしては、スレッドのリスト解除を時々使用しますが、これはすべて戦闘的な新規ユーザーに関するものです。多くの場合、検閲の兆候に非常に腹を立てるようなタイプの人々です。そして、私は本当に物事を検閲/非表示/削除したくありません。全体的な目的は、それ自体でより多くの不満を引き起こす可能性が低いと思われるソフトな介入であり、それでも温度を少し低く保つのに役立つことを願っています。
これは、Hacker Newsがコメント数が投票数を大幅に上回るトピックをペナルティする仕組みに多少触発されています。
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2022 年 1 月 18 日午後 5:10 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/9 "2022-01-18T17:10:44Z")
> [@mbauman](#):
>
> ユーザーに表示される内容については、それを伝える必要が100%あるとは確信していませんが、「リストにない」投稿アイテムのように表示される可能性があります。「このトピックはX時間ごとにトピックリストの一番上に表示されます」と単純に述べるだけです。
@sam @eviltrout、この件についてどう思われますか？ここに時間を表す整数を入れることができます。0は「決して引き上げられないようにする」、1〜6000は「{x}分ごとに1回だけ引き上げを許可する」といった意味になります。
---
### Author:  [@eviltrout](https://meta.discourse.org/u/eviltrout)
#### Post date: [2022 年 1 月 18 日午後 5:28 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/10 "2022-01-18T17:28:29Z")
面白いアイデアですね。バンプに対するデバウンスのようなものです。
パワーツールのように見えますが、役立つと思います。追加するのは簡単なことではないと思います。おそらく中程度の労力が必要でしょう。
---
### Author:  [@saquetim](https://meta.discourse.org/u/saquetim)
#### Post date: [2022 年 1 月 18 日午後 7:17 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/11 "2022-01-18T19:17:22Z")
最初の段階でモデレーションによってトピックが過熱するのを防ぐことは、特にユーザーが多い場合に、いくつかのシナリオで役立つと思います。
トピックがすでに過熱しており、議論が自己維持されている場合、スレッド内のインタラクションからユーザーが受け取る通知がそれを継続させる可能性が高いため、スローモードの方がうまく機能するでしょう。
ソースコードを確認したところ、モデルを変更する以外に、`bypass_bump?` を変更するだけでトピックが再び表示されるのを防ぐことができるでしょうか？
>
たとえば、`Topic` に `min_seconds_between_bumps` のようなフィールドを追加し、`bypass_bump?` に別の条件を追加する必要があるかもしれません。
```ruby
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の観点からは良いと思います。
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [2022 年 1 月 18 日午後 7:50 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/12 "2022-01-18T19:50:38Z")
> [@saquetim](#):
>
> 例えば `Topic` に `min_seconds_between_bumps` のようなフィールドを追加し、`bypass_bump?` に別の条件を追加してはどうでしょうか。
もし私の解釈が正しければ、返信が投稿された時点でスレッドを上げるかどうかの判断が行われますが、スレッド上げ禁止期間後に後続の返信が投稿されなかった場合、そのスレッドは決してスレッド上げされなくなります。
これは望ましい動作でしょうか、それとも期間中に返信があった場合、スレッドは常に期間終了時にスレッド上げされるべきでしょうか？常にスレッド上げされるべき場合、それは「現在」にスレッド上げされるべきか、それとも最新の返信時刻にスレッド上げされるべきでしょうか？
---
### Author:  [@saquetim](https://meta.discourse.org/u/saquetim)
#### Post date: [2022 年 1 月 18 日午後 8:07 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/13 "2022-01-18T20:07:44Z")
> [@Simon\_Manning](#):
>
> もし私の解釈が正しければ、バンプ（トピックの更新）を解除するかどうかの決定は返信が投稿された時に行われ、バンプ禁止期間後に後続の返信が投稿されなければ、トピックは決してバンプされなくなります。
はい、このアプローチでは、決定は返信が投稿された時に行われ、後続の返信がなければトピックが再びバンプされることはありません。Discourseのソースコードの専門家ではないので確信はありませんが、これが実装する上で簡単な方法になるでしょう。
クールダウン期間後にバンプするという他の可能な動作は、@eviltroutが言ったように、より多くの作業が必要になるでしょう。なぜなら、アプリケーションが次に期待されるバンプを保存し、保留中のバンプを定期的に実行するためのスケジューラまたはsidekiqジョブのようなものが必要になるからです。
どちらのアプローチも有効であり、これが実装されるとしても、どちらが選択されるかはわかりません。
個人的には、後続の返信がない場合に問題のあるトピックが二度とバンプされなくても気にしません。しかし、それはあくまで私の意見です。
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2022 年 1 月 19 日午前 1:12 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/14 "2022-01-19T01:12:23Z")
私の考えでは、最もシンプルなロジックは次のとおりです。
- トピックには「{x} 分ごとに 1 回しか BUMP できません」という設定があり、分数は調整可能な設定で、ゼロ（デフォルトでは、返信の数だけ BUMP できます）から約 10,000（週に 1 回しか BUMP できません）まであります。誰かが 60 分を入力したと仮定すると、トピックは最大 60 分ごとに 1 回しか BUMP できません。
- **返信が投稿されたとき** に、最後の BUMP 日付を確認します。
はい、これはシンプルで実用的なようです。次のリリースに追加しましょうか @sam @eviltrout？
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [2022 年 1 月 19 日午前 1:40 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/15 "2022-01-19T01:40:41Z")
> [@codinghorror](#):
>
> デフォルトのゼロ（返信の数だけ増やすことができる）から約10,000（週に1回しか増やすことができない）まで
-1（無期限に増やすことができない）も価値があるでしょうか？私はそうではない方に傾いています。そのようなトピックを後で見つけるのは難しいでしょう（追加の作業なしでは）、そして管理者がトピックを絶対に増やしたくないのであれば、単に閉じる方が理にかなっているでしょう。
---
### Author:  [@clazmama](https://meta.discourse.org/u/clazmama)
#### Post date: [2022 年 10 月 4 日午後 9:35 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/16 "2022-10-04T21:35:55Z")
> [@codinghorror](#):
>
> ゼロ（デフォルト、返信の数だけ増やすことができます）から約10,000（週に1回しか増やすことができません）までの範囲
実際、最大時間設定は管理者ページで設定可能な設定であるべきだと思います。`max_slowbump_time`のようなものです。
また、ついでに。カテゴリレベルでスローバンプを適用することも可能でしょうか？
---
### Author:  [@Keno](https://meta.discourse.org/u/Keno)
#### Post date: [2025 年 11 月 11 日午後 2:48 UTC](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080/17 "2025-11-11T14:48:51Z")
このような機能は実装されましたか？ 元々@mbaumanがリクエストしたスレッドがあり、この機能が現在利用可能であれば、それを使用できると素晴らしいです。