注意：有一个看似相似的话题 关于话题摘要，但实际上与我提议的内容大不相同，尽管某些元素可能相似。
在话题顶部添加一个摘要部分，你觉得这会很有用吗？
这个想法在我的清单上已经很久了，我相信它有可能彻底改变讨论方式。
我一直觉得，如果我只想了解当前的进展状态，阅读线程中的所有帖子可能会太过冗长。（当然，跟随思想的演变并获得更深入的见解是很好的，但并不是每个人都有时间这样做。）而且直接跳到结尾也不行，因为真正重要的帖子可能位于中间。特别是在那些旨在讨论如何改进某些事物的论坛上，可能会有很多起伏和反复，而我真正希望拥有的是某种能总结所有这些内容的东西，最好是在最开头，这样我就能了解情况，只需花一分钟即可。
这个摘要将如何运作？
我设想的 summary 是一个可编辑的文本字段，就像任何帖子一样，任何人都可以对其进行修改，就像维基百科一样。可能的修改应仅在用户也在该线程中发布内容时才被允许，这可以作为修改摘要的理由。
让我用这段对话本身作为例子来说明：
假设第一个人（我）发起一个新话题，并发布初始帖子（即本文）。
Discourse 随后会提示我：“您想编辑摘要吗？”
我会回答“好的”，并为摘要添加第一段文字：
摘要可以帮助新人快速跟上进度，并有助于社区得出更好的结论。
到目前为止一切顺利。现在，用户 B 加入，并可能这样回复：
“我不确定这样做是否值得。我想象实现起来会相当困难，而且这难道不会只是增加噪音吗？”发布后，系统会提示他是否更新摘要：
摘要可以帮助新人快速跟上进度，并有助于社区得出更好的结论。不过，它可能会增加噪音，且实现起来并不容易。
第三位用户 C 说：“我认为这会是个很棒的想法，但我同意 B 的观点，可能不值得花这么多精力。……除非……我们能否在提案和投票中也使用它 <small>[或者该社区感兴趣的其他内容]</small>？嗯，也许我们应该列出利弊，你们怎么看？”C 决定不更新摘要，因为他不确定自己能做出什么改进。
第四位用户 D 说：“是的，这对我们的用户参与度以及在提出提案的过程中完全可行。而且我赞同 C 关于列出利弊的想法，我还有更多补充：
我们可以让每次编辑都关联到编辑者，点击时直接跳转到该帖子，这基本上是一种快速导航。对吧？”
摘要可以：
- 帮助新人快速跟上进度
- 帮助社区得出更好的结论
- 充当“快速导航”
- 不仅限于此 Discourse 论坛
然而，可能的缺点包括：
- 可能会增加噪音
- 实现起来可能不容易。
B 再次介入：“等等，等一下。在我们深入这个细节之前，这个摘要到底应该总结什么？它只是对每篇帖子的重述吗？那似乎没什么意义，对吧？我们能否先给出一个定义？我认为它应该只总结真正重要的内容，即那些有助于回答原始提问者（OP）问题的内容，对吧？否则，我坚持之前的观点，即它只会产生更多噪音，或增加用户需要输入的内容以及 UI 开销等……
顺便说一句，D，我觉得你的“快速导航”有点难以理解，所以我稍微修改了一下，希望现在这样没问题？”
摘要应总结帖子中所有有助于回答作者问题的相关内容。
它可以：
- 帮助新人快速跟上进度
- 帮助社区得出更好的结论
- 摘要中的部分可以超链接到编辑者
- 不仅限于此 Discourse 论坛
然而，可能的缺点包括：
- 可能会增加噪音
- 实现起来可能不容易。
用户 D 说：“是的，谢谢 B，你说得对，我表达的意思确实不明显。不过，我仍然希望在那里提到“快速导航”，因为在我看来这是一个相对独立的观点。将某些内容链接起来能提供一点……验证？真实性？我不确定该用什么词……
哦，再稍微重述一下我最初关于在此 Discourse 论坛之外使用它的观点……
我实际上想表达的是，我认为它不仅可以用于我们关注的提案和投票。例如，它可以用于跟踪任务进度、某种状态，也可以对任何问题提供更全面的见解……可能性是无限的。”
摘要应总结帖子中所有有助于回答作者问题的相关内容。
它可以：
- 帮助新人快速跟上进度
- 帮助社区得出更好的结论
- 摘要中的部分可以超链接到编辑者
- 快速导航到各个陈述的详细信息
- 不仅适用于提案和投票，用途广泛
然而，可能的缺点包括：
- 可能会增加噪音
- 实现起来可能不容易。
然后用户 X 加入，看到这个版本的摘要，除了“超链接到编辑者”这一部分外，其他都很直观。他将鼠标悬停在该部分上，会看到用户 D 的帖子是第一个链接条目，用户 B 的帖子是第二个。（某种悬停提示信息）。他可以直接点击链接跳转到 D 的帖子并阅读详细信息，随后是 B 的帖子（中间可能还有其他帖子，但因为未对修改做出贡献而被折叠）。
……好的，希望你们能明白我的意思。
快速跟进是不是超级轻松？（如果你想象只需要阅读那个摘要的话！）
好吧，要写出这个插件的所有细节可能并不容易（这个插件还能做很多其他事情，其中一些我尚未命名的最爱功能包括根据与贡献博客帖子相关的投票/反应来增加或减少字体大小/粗细/颜色），其中一些逻辑可能有点棘手（例如，正确地将修改部分归因于作者，以及可视化如果有人删除了一个“不”字会发生什么等……），但我相信这一切都是可行的，并且能为许多讨论带来巨大的价值。
（这比我原本想写的要多得多，但构思这个例子很有趣 
）
你们怎么看？
这种插件在 Discourse 生态系统中在技术上真的可行吗？
你们需要更多信息吗？需要更正式的模拟图吗？（我不擅长这个，但可以尝试制作一些）
免责声明：
我可以尝试自己开发这个插件，我也可能会这么做，但目前我没有任何 Ruby / Ember / Discourse 开发经验，所以需要很长时间。
此外，这个想法已经有些年头了，但在一个社区群体中引起了更多关注，他们觉得这会非常有帮助，所以我可能会在那里开发并进行一些“吃狗粮”（内部测试）……但同样，这需要我花费很长时间。如果它对 Discourse 有价值，那么有你们中的某些人参与将会非常棒！
祝好 
