更柔和的慢速模式：慢速颠簸？

功能
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

我不太明白你的提议。你能给我展示一个用户界面模型，说明这将如何运作，用户会看到什么，工作人员又会看到什么？

这就是为什么在慢速模式下默认限制编辑。如果你信任你的社区不会这样做，你可以关闭编辑限制。

另外，请考虑@sam的说法。将帖子设为未列出。 在提议更多功能之前，请_充分_利用你工具箱中现有的工具。

8

核心思想很简单：我会在管理员主题菜单中将其命名为“限制主题置顶…”（可能位于“：anchor: 重置置顶日期”项目旁边）。它会弹出一个模态框，提示您输入时间段。文本将是这样的：“将此主题出现在“最新”和其他类别视图顶部的频率限制为最多每 X 小时一次”，默认值为 8 小时。

我并不特别在意它的实现方式；它可以是状态化的（跟踪置顶主题更新时间的最后一个帖子，并且仅当新帖子的时间比 X 小时后才更新）或者它可以是无状态的（始终将主题更新时间设置为从 Unix 纪元或第一个帖子开始的 X 小时整数倍）。或者其他方式，随便。

至于向用户显示什么，我并不完全确定是否 需要 告知他们，但它可以显示为一个“未列出”的帖子项目，简单说明：“此主题将每 X 小时才会在主题列表顶部显示一次。”

至于其他工具，我们有时会使用线程取消列出，但这都是针对具有攻击性的新用户——通常是那种可能对任何审查暗示非常不满的人。而且我真的 不希望 审查/隐藏/删除东西。整个要点是一种更温和的干预，希望不太可能引起更多的愤怒，但有望帮助保持一点凉意。

这在某种程度上受到了 Hacker News 惩罚评论远多于点赞的主题方式的启发。

2 个赞
9

您对此有何看法 @sam @eviltrout？我们可以设置一个代表时间的整数，其中 0 表示“永不允许其置顶”，1-6000 表示“允许每 {x} 分钟置顶一次”之类的。

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 这个值是否表示主题根本不应该被顶起。这可能会让一些用户感到困惑。如果这样做，我认为如果 Web 应用不直接向用户显示零值，用户体验会更好。

3 个赞
12

如果我的理解正确，是否顶帖的决定将在回复发布时做出，但如果在 no-bump 期间没有后续回复，则该主题将永远不会被顶帖。

这是期望的行为吗？还是说，如果在 no-bump 期间发布了回复，该主题应该总是在 no-bump 结束时被顶帖？如果应该总是在 no-bump 结束时被顶帖，应该顶帖到“现在”还是最新回复的时间？

2 个赞
13

是的，在这种方法中，决定将在回复发布时做出，如果没有后续回复，该主题将永远不会被置顶。如果我没记错的话，因为我绝不是 Discourse 源代码方面的专家，这将是实现这一目标的最简单方法。

另一种可能的行为，即在冷却期后置顶，可能需要更多的工作，正如 @eviltrout 所说，因为它需要应用程序存储下一个预期的置顶时间，并具有某种调度程序或 sidekiq 作业来定期执行待定的置顶。

这两种方法都是有效的，如果将来真的实现了，我也不知道会选择哪一种。

就我个人而言，如果一个有问题的帖子在没有后续回复的情况下永远不会被置顶，我并不介意。但这只是我的个人观点。

2 个赞
14

我的想法是最简单的逻辑是这样的：

  • 主题有一个设置，“每 {x} 分钟只能置顶一次”，其中分钟数是一个可调设置，范围从零（默认值，可以根据回复次数置顶任意次数）到约 10,000（每周只能置顶一次）。假设有人输入了 60 分钟，那么主题最多每 60 分钟才能置顶一次。

  • 当发布回复时，检查上次置顶日期：

    • 如果上次置顶日期距现在超过 60 分钟，则允许通过此新回复置顶主题。

    • 如果上次置顶日期距现在不到 60 分钟，则在此新回复发布时_不置顶主题_。

是的，这似乎很简单并且可行……我们将其添加到下一个版本吧 @sam @eviltrout？

6 个赞
15

-1（不能无限期增加）是否也有价值？我认为倾向于否，因为以后很难（不付出额外努力）找到这样的主题，而且如果管理员确实希望某个主题永远不再被增加，那么直接关闭它可能更有意义。

16

我实际上认为最大时间设置应该是一个可配置的管理员页面设置。比如 max_slowbump_time 或者其他什么。

另外，既然我们谈论到这个话题。是否也可以将慢速提升应用于分类级别？

17

有过类似的功能被实现吗？我们有另一个类似的帖子，促使 @mbauman 最初请求该功能，如果现在有此功能，将非常乐意使用它。