より穏やかなスローモード：スローバンプ？

特徴
1

I really like the intention behind slow mode, but it doesn’t quite address the most common driver for flamewars on our discourse:

  • Someone comes in “hot” — often someone new, often someone from another community — and lists a bunch of grievances
  • Lots of existing members respond to talk to/at the original poster with varying motivations (but with the “I think someone is wrong on the internet” syndrome ranking high)
  • The original poster wants to respond to/at everyone
  • Even in the best of discussions, things snowball rapidly.

Slow mode doesn’t help here, because there’s a many-to-one problem. It often just further alienates the new member as they’re the one that feels the brunt of the limitation: many can respond to them while their cool down timer is burning and then they only get one post to respond.

One tool I wish I had in my toolbox for situations like these is to slow down the bumping of the topic. The default listings (both latest and top) prioritize these “hot” topics. I’d love to be able to limit the bumps to once-every-12-hours or some such. Then it’s not a complete de-listing, but it’s a significant de-emphasizing that could help limit the number of new entrants to the discussion (unless they actively seek it out, which is just fine).

「いいね！」 16
2

A motivated user could write a single reply and quite many other posters though, right? ….that still would be possible in slow mode.

But I do agree that a reduced-bumping would also be useful in slow-mode. :slight_smile:

「いいね！」 2
3

Absolutely, but such monster posts that reply to many messages make the topic even harder to manage. Splits become impossible, and they tend to put the poster even more on a war-path (or at the very least, give the appearance of aggravation just by virtue of the large wall of text).

「いいね！」 5
4

That’s actually another unintended consequence of slow mode that we’ve seen on Julia discourse, which is a paid hosted instance that’s quite active: slow mode gets turned on and some people start editing their posts instead of writing new ones. Similar problem with setting someone who’s being problematic to TL0: they can’t make new posts but they can still edit their old ones, so they’ll do that, which is especially bad if they’re written inflammatory stuff which people reply to and they then edit, making the response look out of line.

But yes, I definitely second @mbauman’s suggestion—being able to prevent a hot topic from getting bumped so often would be very helpful for cooling things down.

「いいね！」 3
5

In addition to preventing the hot topic from getting bumped, it might be an idea to delay the notifications. That kind of solves the issue where someone replies to or mentions multiple users.

「いいね！」 4
6

A trick you can use today is to make topics like this unlisted, we do plan to add timers that can relist, but you could do that by hand

“Bury” topic has popped up in the past, and something we have thought about

「いいね！」 5
7

提案されている内容がよく理解できません。これがどのように機能するのか、ユーザーには何が見え、スタッフメンバーには何が見えるのか、UIモックアップを見せていただけますか？

だからこそ、スローモードではデフォルトで編集が制限されています。コミュニティがそのようなことをしないと信頼できる場合は、編集制限をオフにすることができます。

そして、@samが言ったことを検討してください。トピックをリストから外してください。 新しいツールを提案する前に、ツールキット内の既存のツールを最大限に活用してください。

8

主なアイデアは非常にシンプルです。管理者のトピックメニューにある「:anchor: Bump Dateをリセット」項目の隣に、「トピックのBumpを制限…」のような名前で配置します。すると、時間間隔を入力するモーダルボックスが表示されます。「このトピックが最新表示やその他のカテゴリ表示の一番上に表示される頻度を、X時間ごとに最大1回に制限します」といったテキストが表示され、デフォルトは8時間程度になります。

実装方法についてはあまりこだわりはありません。ステートフル（トピックの更新時間をBumpした最後の投稿を追跡し、新しい投稿の時間がX時間後より後である場合にのみ更新する）でも、ステートレス（トピックの更新時間を、Unixエポックまたは最初の投稿からX時間の倍数のフロア値に常に設定する）でも構いません。あるいは、何か別の方法でも良いです。

ユーザーに表示される内容については、必ずしも伝える必要はないかもしれませんが、「このトピックはトピックリストの一番上にX時間ごとに1回しか表示されません」というシンプルな「リスト外」の投稿アイテムとして表示される可能性があります。

他のツールとしては、スレッドのリスト解除を時々使用しますが、これはすべて戦闘的な新規ユーザーに関するものです。多くの場合、検閲の兆候に非常に腹を立てるようなタイプの人々です。そして、私は本当に物事を検閲/非表示/削除したくありません。全体的な目的は、それ自体でより多くの不満を引き起こす可能性が低いと思われるソフトな介入であり、それでも温度を少し低く保つのに役立つことを願っています。

これは、Hacker Newsがコメント数が投票数を大幅に上回るトピックをペナルティする仕組みに多少触発されています。

「いいね！」 2
9

@sam @eviltrout、この件についてどう思われますか？ここに時間を表す整数を入れることができます。0は「決して引き上げられないようにする」、1〜6000は「{x}分ごとに1回だけ引き上げを許可する」といった意味になります。

「いいね！」 1
10

面白いアイデアですね。バンプに対するデバウンスのようなものです。

パワーツールのように見えますが、役立つと思います。追加するのは簡単なことではないと思います。おそらく中程度の労力が必要でしょう。

「いいね！」 1
11

最初の段階でモデレーションによってトピックが過熱するのを防ぐことは、特にユーザーが多い場合に、いくつかのシナリオで役立つと思います。

トピックがすでに過熱しており、議論が自己維持されている場合、スレッド内のインタラクションからユーザーが受け取る通知がそれを継続させる可能性が高いため、スローモードの方がうまく機能するでしょう。

ソースコードを確認したところ、モデルを変更する以外に、bypass_bump? を変更するだけでトピックが再び表示されるのを防ぐことができるでしょうか？

たとえば、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
12

もし私の解釈が正しければ、返信が投稿された時点でスレッドを上げるかどうかの判断が行われますが、スレッド上げ禁止期間後に後続の返信が投稿されなかった場合、そのスレッドは決してスレッド上げされなくなります。

これは望ましい動作でしょうか、それとも期間中に返信があった場合、スレッドは常に期間終了時にスレッド上げされるべきでしょうか？常にスレッド上げされるべき場合、それは「現在」にスレッド上げされるべきか、それとも最新の返信時刻にスレッド上げされるべきでしょうか？

「いいね！」 2
13

はい、このアプローチでは、決定は返信が投稿された時に行われ、後続の返信がなければトピックが再びバンプされることはありません。Discourseのソースコードの専門家ではないので確信はありませんが、これが実装する上で簡単な方法になるでしょう。

クールダウン期間後にバンプするという他の可能な動作は、@eviltroutが言ったように、より多くの作業が必要になるでしょう。なぜなら、アプリケーションが次に期待されるバンプを保存し、保留中のバンプを定期的に実行するためのスケジューラまたはsidekiqジョブのようなものが必要になるからです。

どちらのアプローチも有効であり、これが実装されるとしても、どちらが選択されるかはわかりません。

個人的には、後続の返信がない場合に問題のあるトピックが二度とバンプされなくても気にしません。しかし、それはあくまで私の意見です。

「いいね！」 2
14

私の考えでは、最もシンプルなロジックは次のとおりです。

  • トピックには「{x} 分ごとに 1 回しか BUMP できません」という設定があり、分数は調整可能な設定で、ゼロ（デフォルトでは、返信の数だけ BUMP できます）から約 10,000（週に 1 回しか BUMP できません）まであります。誰かが 60 分を入力したと仮定すると、トピックは最大 60 分ごとに 1 回しか BUMP できません。

  • 返信が投稿されたときに、最後の BUMP 日付を確認します。

    • 最後の BUMP 日付が 60 分以上前の場合、この新しい返信でトピックを BUMP することを許可します。

    • 最後の BUMP 日付が 60 分未満の場合、この新しい返信を投稿するときにトピックを BUMP しません。

はい、これはシンプルで実用的なようです。次のリリースに追加しましょうか @sam @eviltrout？

「いいね！」 6
15

-1（無期限に増やすことができない）も価値があるでしょうか？私はそうではない方に傾いています。そのようなトピックを後で見つけるのは難しいでしょう（追加の作業なしでは）、そして管理者がトピックを絶対に増やしたくないのであれば、単に閉じる方が理にかなっているでしょう。

16

実際、最大時間設定は管理者ページで設定可能な設定であるべきだと思います。max_slowbump_timeのようなものです。

また、ついでに。カテゴリレベルでスローバンプを適用することも可能でしょうか？

17

このような機能は実装されましたか？ 元々@mbaumanがリクエストしたスレッドがあり、この機能が現在利用可能であれば、それを使用できると素晴らしいです。