我非常认同慢速模式背后的初衷，但它并未真正解决我们 Discourse 上引发骂战的最常见诱因：
慢速模式在此无济于事，因为这是一个“多对一”的问题。它往往进一步疏远了新成员，因为他们才是承受限制压力的一方：许多人可以在他们的冷却计时器倒计时期间回复他们，而他们却只能发一条帖子进行回应。
我希望在这样的场景中，我的工具箱里能有这样一个工具：减缓主题的“顶帖”（bumping）频率。默认的列表（包括“最新”和“热门”）会优先展示这些“热门”话题。我希望能将顶帖频率限制为每12小时一次，或类似设置。这样并非完全将主题从列表中移除，而是显著降低其曝光度，从而有助于限制参与讨论的新增人数（除非他们主动寻找该话题，这当然也没问题）。
有动力的用户确实可以只发一条回复，却能让很多其他帖子被顶起来，对吧？……在慢速模式下这仍然是可能的。
不过我也同意，在慢速模式下增加“减少顶帖”的功能会很有用。
完全正确，但这类回复多条消息的“怪物级”帖子会让话题更难管理。分割变得不可能，而且它们往往会 更加 激怒发帖人（或者至少，仅凭那一大段文字墙，就 看起来 像是在加剧矛盾）。
这实际上是我们在 Julia 论坛 上观察到的慢速模式的另一个意外后果。该论坛是一个付费托管实例，非常活跃：慢速模式被启用后，一些人开始编辑自己的帖子，而不是发布新帖子。类似的问题也出现在将制造麻烦的用户设置为 TL0 时：他们无法发布新帖子，但仍可以编辑旧帖子，因此他们会这样做。如果他们之前发布了煽动性内容，而其他人已经对此进行了回复，随后他们再编辑这些内容，就会使回复显得不合时宜。
不过，我确实完全赞同 @mbauman 的建议——能够防止热门话题被频繁顶起，对于平息事态将非常有帮助。
除了防止热门话题被顶起之外，延迟通知可能也是一个好主意。这样可以解决有人回复或提及多个用户的问题。
今天可以使用的一个技巧是将此类主题设为不公开。我们计划添加可重新公开的计时器，但您现在也可以手动操作。
“沉帖”功能过去曾被提及，也是我们考虑过的一项功能。
我不太明白你的提议。你能给我展示一个用户界面模型，说明这将如何运作，用户会看到什么，工作人员又会看到什么？
这就是为什么在慢速模式下默认限制编辑。如果你信任你的社区不会这样做，你可以关闭编辑限制。
另外，请考虑@sam的说法。将帖子设为未列出。 在提议更多功能之前，请_充分_利用你工具箱中现有的工具。
核心思想很简单：我会在管理员主题菜单中将其命名为“限制主题置顶…”（可能位于“：anchor: 重置置顶日期”项目旁边）。它会弹出一个模态框，提示您输入时间段。文本将是这样的：“将此主题出现在“最新”和其他类别视图顶部的频率限制为最多每 X 小时一次”，默认值为 8 小时。
我并不特别在意它的实现方式；它可以是状态化的（跟踪置顶主题更新时间的最后一个帖子，并且仅当新帖子的时间比 X 小时后才更新）或者它可以是无状态的（始终将主题更新时间设置为从 Unix 纪元或第一个帖子开始的 X 小时整数倍）。或者其他方式，随便。
至于向用户显示什么，我并不完全确定是否 需要 告知他们，但它可以显示为一个“未列出”的帖子项目，简单说明：“此主题将每 X 小时才会在主题列表顶部显示一次。”
至于其他工具，我们有时会使用线程取消列出，但这都是针对具有攻击性的新用户——通常是那种可能对任何审查暗示非常不满的人。而且我真的 不希望 审查/隐藏/删除东西。整个要点是一种更温和的干预，希望不太可能引起更多的愤怒，但有望帮助保持一点凉意。
这在某种程度上受到了 Hacker News 惩罚评论远多于点赞的主题方式的启发。
您对此有何看法 @sam @eviltrout？我们可以设置一个代表时间的整数，其中 0 表示“永不允许其置顶”，1-6000 表示“允许每 {x} 分钟置顶一次”之类的。
这是一个有趣的想法——有点像“防抖”处理“颠簸”。
这看起来像是一个强大的工具，但我认为它会很有用。我不认为这是一个容易添加的功能——可能需要中等程度的努力。
我认为，如果能在早期被版主发现，在某些场景下可以防止一个主题过热。尤其是在用户量很大的情况下。
如果主题已经过热并且讨论是自我维持的，那么慢速模式可能会做得更好，因为用户从主题互动中收到的通知（可能）会使其继续下去。
我查看了源代码，除了更改模型之外，更改 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 应用不直接向用户显示零值，用户体验会更好。
如果我的理解正确，是否顶帖的决定将在回复发布时做出，但如果在 no-bump 期间没有后续回复，则该主题将永远不会被顶帖。
这是期望的行为吗？还是说，如果在 no-bump 期间发布了回复，该主题应该总是在 no-bump 结束时被顶帖？如果应该总是在 no-bump 结束时被顶帖，应该顶帖到“现在”还是最新回复的时间？
是的，在这种方法中，决定将在回复发布时做出，如果没有后续回复，该主题将永远不会被置顶。如果我没记错的话，因为我绝不是 Discourse 源代码方面的专家，这将是实现这一目标的最简单方法。
另一种可能的行为，即在冷却期后置顶，可能需要更多的工作，正如 @eviltrout 所说，因为它需要应用程序存储下一个预期的置顶时间，并具有某种调度程序或 sidekiq 作业来定期执行待定的置顶。
这两种方法都是有效的，如果将来真的实现了，我也不知道会选择哪一种。
就我个人而言，如果一个有问题的帖子在没有后续回复的情况下永远不会被置顶，我并不介意。但这只是我的个人观点。
我的想法是最简单的逻辑是这样的：
主题有一个设置，“每 {x} 分钟只能置顶一次”，其中分钟数是一个可调设置，范围从零（默认值，可以根据回复次数置顶任意次数）到约 10,000（每周只能置顶一次）。假设有人输入了 60 分钟，那么主题最多每 60 分钟才能置顶一次。
当发布回复时，检查上次置顶日期：
如果上次置顶日期距现在超过 60 分钟，则允许通过此新回复置顶主题。
如果上次置顶日期距现在不到 60 分钟，则在此新回复发布时_不置顶主题_。
是的，这似乎很简单并且可行……我们将其添加到下一个版本吧 @sam @eviltrout？
-1（不能无限期增加）是否也有价值？我认为倾向于否，因为以后很难（不付出额外努力）找到这样的主题，而且如果管理员确实希望某个主题永远不再被增加，那么直接关闭它可能更有意义。
我实际上认为最大时间设置应该是一个可配置的管理员页面设置。比如 max_slowbump_time 或者其他什么。
另外，既然我们谈论到这个话题。是否也可以将慢速提升应用于分类级别？
有过类似的功能被实现吗？我们有另一个类似的帖子，促使 @mbauman 最初请求该功能，如果现在有此功能，将非常乐意使用它。