Discourse 最近的一项更改移除了编辑帖子（主题中的最后一个或第一个帖子）时产生的“顶帖”效果。
这是我们一直依赖的一项功能，并且对于非工作人员级别的成员来说，没有可行的替代方法来模仿此功能。
我们主要从这项功能中受益，用于“顶起”那些公告式帖子或那些故意没有/很少回复的帖子。
这些是主题的真实更新，其中编辑移除了现已过时的信息。帖子重新出现在最新动态列表的顶部是非常受欢迎的，因为它告知所有成员有变化发生。
是的，这在一定程度上可以通过一系列回复来模仿，但随着时间的推移，用户收集所传达的信息会变得麻烦（想象一下 10 个带有更改的回复，例如）。编辑原始帖子/最新帖子并让主题在最新动态中上升要干净得多。
我理解人们对此会有不同的看法，但这在 Discourse 中是一个长期存在的先例多年，为恢复以前的功能向 Discourse 添加一个选项将使每个人都满意。也许可以随着时间的推移扩展这种选择性，以便精确控制帖子上的哪些活动会使其在最新动态中上升。
下面是讨论此更改的 Bug 帖子的链接：
我还没有达到所需的信任级别，因此无法对此进行投票，但如果可能的话，我也想表示赞同这项更改。
正如我之前所说，我也很怀念在有有意义的编辑时主题会被顶起。
我使用 rss-polling 来通过 https://status.discourse.org/ 的 RSS 源接收有关我论坛维护的通知。维护开始时会创建一个主题，当宣布维护结束的编辑发生时，该主题会被顶起。现在缺少了这个顶起，而且我不想让这些主题成为维基（wiki），因为不应有用户编辑它们，我也不想让它们成为文档（docs）。因此，目前的变通方法没有帮助。
在一个论坛中，我们有一个展示用户项目的画廊主题，以及用户展示他们项目的单独主题。这个主题对于收集灵感非常有帮助。我们会从展示主题中添加一张图片并附上链接到这个画廊主题中。帖子中过多的图片导致了性能问题，也使得编辑更加困难。因此，我们每 10 个项目就创建一个新帖子。在添加第 2 个或第 9 个项目时进行的编辑所带来的顶起曾经很有帮助。这有助于用户注意到更新，对于那些手动向主题添加项目的人来说尤其有帮助。由于有了活动日期，我能立即看到是否有人已经添加了该项目。现在，我们每个人都需要打开主题来检查这一点。
还有其他主题以类似的方式运作：一些主题作为每月变更/活动的总结概览，其中关于当前月份的最新帖子会更新几次。这效果非常好，因为对最后一个帖子的更改会顶起该主题。单独发布每项更改会影响到每月捆绑条目的清晰度，并且仍然意味着现有条目的更新很容易被错过。每月为少量条目创建一个新主题感觉太多了，而且这也意味着用户需要每月重新设置他们的通知，或者我们需要一个完整的子版块，允许他们设置默认通知状态。
我也很喜欢未回答主题的分类和标签更改会顶起它们。大多数时候我使用的是最新主题的（过滤后的）列表。如果一个主题的标题选择不当或位于错误的分类中，我可能不会点击它。如果有人改进了这些信息，我可能会意识到我仍然可以提供帮助。这就是为什么这种更改能让主题移回我的已读标记之上很有帮助。
此外，了解分类和标签也很有帮助。我经常通过新主题上添加的标签或版主移动主题所展示的分类之间的详细区别来了解新标签。我有时甚至会询问原因，因为我认为移动主题到其他分类的能力也伴随着了解它们之间区别的责任。
我也喜欢 Discourse 的设置会强制您添加信息而不是撰写另一个帖子的做法。
引用弹出消息：
然而，这只有在其他人注意到您编辑了帖子以添加更多信息时才有意义。我在 Meta 上遇到过几次这样的例子，是在拉取请求（pull request）合并后对帖子进行更新。将该信息添加到帖子中不会通知那些已经阅读过帖子的人，而那些没有阅读过的人可以通过 onebox 中的徽章很容易地看出来。
对我来说，阻止用户连续回复超过三次的设置仍然有效并建议编辑作为解决方案是没有意义的，因为这些编辑不幸地不再具有它们曾经拥有的效果了。
我对这个功能没有强烈的意见，但一个相关的问题是，我喜欢自动顶帖子，然后删除关于它被顶的消息，但现在做不到了。当我删除顶帖消息时，帖子会沉回它之前的位置。如果编辑帖子可以使其被顶，而又不会产生“最后顶于 1 天前”的提示，那将很有用。
（我更希望能够顶帖子，删除顶帖消息，并且帖子仍然保留在首页上，除非我手动执行“重置顶帖日期”。）
很有趣的想法，任何能恢复编辑帖子能将其提升到活动信息流顶部的功能都将受到欢迎
@lindsey 有什么办法可以恢复部分此功能，还是说现在已经太晚了，这就是新的常态了
我恐怕我们目前没有恢复所有编辑中“顶起”（bump）功能的计划。我理解这不是您想听到的答案，但我们会继续关注此主题，并考虑将来如何更好地支持您的使用场景。
某件事不再发生，这种情况本身也难以被发现。有没有关于有多少管理员注意到了 Discourse 的行为已经改变的数据？我理解你的观点，即反复有人要求如何阻止顶帖。很明显，管理员会注意到他们不想要的顶帖。但是，如果一个主题没有被顶，你甚至不会注意到它没有被顶，尽管你可能希望它被顶。所以人们提出这种请求的可能性似乎更小。
例如，我希望能够注意到这个帖子的编辑，它将“我将尝试”改为了一个后续问题。就像看到其他帖子上的编辑一样，比如 Localization of posts on topics with more than 20 posts - #7 by nat 会很好。
此外，最近关于如果主题被顶帖，垃圾信息更容易被注意到的问题再次出现。我想知道为什么这在现在编辑时应该顶帖的相当有限的情况下才相关。但当更改大多数帖子的默认设置时，这并不重要。为什么一个作为 wiki 的首帖比一个作为 wiki 的主题的最后一帖需要更多的垃圾信息保护？
正如我以前多次说过的，我理解优点，但似乎没有太多人有兴趣寻找解决缺点的办法。如果一年左右后才出现替代当前工作流程的方案，那就没什么用了。我现在必须找到一个新的解决方案，因为在有支持的 Discourse 版本中，编辑最后一篇帖子会将主题移到顶部的时间已经不多了。
这完全不是出于减少垃圾信息传播的动机。
Wiki 和文档帖子的“顶起”（bump）是基于这样一个理论：对这些帖子的编辑通常是大家感兴趣的。
至于垃圾信息保护，目前的理论是，这些“顶起”从未真正提供多少额外的曝光度。大多数帖子都不是最后一篇，对它们的编辑也从未通过“顶起”来展示。因此，如果通过编辑发送垃圾信息是一个问题，无论如何都需要一个不同的解决方案。这从来都不是解决该问题的有效方法。
我认为存在误解。我的观点不是关于为什么第一帖中的维基帖子会被“顶”。我谈论的是限制 no-bump API 参数背后的原因，正如 GitHub 评论中提到的那样：
这应该仅限于员工 API 密钥吗？ 我不认为我们希望普通用户能够绕过“顶”操作（因为这将允许他们在不引起他人注意的情况下将垃圾邮件注入主题）。
如果垃圾邮件确实是令人担忧的问题，那么这种限制应该一致地适用，而不仅仅是在仍然会发生“顶”操作的少数剩余情况下。这让我感到惊讶：这里的理由引用了垃圾邮件作为一个问题，但在例如是主题中最后一个帖子的维基中，“顶”操作并不被用作垃圾邮件保护机制。
我确实很欣赏维基帖子在更新时会被“顶”（尽管被带到主题底部，而“顶”的原因是第一个帖子，这种用户体验仍然令人困惑）。我的观点只是强调这种关于垃圾邮件的明显不一致之处。
另一个我希望知道最后一条帖子的编辑内容，但因为主题没有被顶起而错过了的例子：Restrict uploads - #30 by Arkshine