Discourse 从一开始就是一个 Ember 应用。
它只是更改了一些结构并标准化了 Ember Components。
请允许我：
5 个赞
我刚有一个想法，还不太成熟，但想先提出来，以免在没有他人意见的情况下过度发展它。
如果 Discourse 能有一种方式，允许人们进行主题式讨论，直到回复达到某个阈值，然后强制人们回复一个链接的主题，或者强烈建议他们这样做，那会怎么样？
对我来说，这可能成为 Discourse 想要成为什么的问题……如果它想成为纯粹的、长篇幅的、专注的对话，那么当前模式似乎效果很好。然而，如果它想成为一个拥有活动、用户目录以及人们之间互动的社区平台，那么我认为添加短篇幅、近乎闲聊的互动可能会有益。
一个例子
我会自动将我的播客剧集发布到我的 discourse（故意使用小写字母以使其通用化，我不确定公司是否会喜欢这个，哈哈），有些剧集是 5-10 分钟，有些则超过 3 小时。
对于一个三小时的播客，我认为人们很难对其进行专注的讨论，因为有些人想评论 00:06:00，而另一些人想评论 01:34:24，还有些人想评论 02:33:50。许多评论可能很短，比如引用部分文字说“哇，我从没这么想过”，或者引用另一部分说“我强烈反对这个”，或者仅仅是想点赞或对不同的部分表示 100% 的赞同。
我相信这些简短的评论可以为社区带来很多价值，不仅能让人们更容易参与，还能引发讨论。也许我看到“我强烈反对这个”并想继续，如果我想继续，也许我会有点激动，想深入探讨。然后他们会更深入地回应。那时我认为主题式讨论就会变得难以管理。
但如果那时软件说，“嘿，开一个链接的主题来深入探讨这个”之类的呢？
闲聊与长篇幅
我认为主题式讨论擅长闲聊，而线性讨论擅长长篇幅，我认为像 Facebook、Instagram、Hacker News、Reddit 以及其他主题式世界的平台很难创建线性讨论，而像 Discourse 这样的线性平台可能更容易添加初始主题式讨论，然后在过长时分裂成线性。实际上，我认为 Facebook 有一个最大嵌套级别，然后也会使对话线性化。
我不知道，也许 Slack 尝试过这个然后失败了，哈哈。
有什么想法吗？
1 个赞
这不就是 Discourse 的工作方式吗？闲聊可以在聊天中进行主题化，而长篇讨论可以在主题中进行。
如果有人在聊天中开始，是的，但如果有人以带有嵌套评论的博文开始，则不行。
我认为我建议的起点更像是 Facebook 或 Instagram 的帖子，或者甚至是 Reddit 的帖子，而我认为您建议的起点更像是 Whatsapp 群组或其他群组聊天，其中有持续的对话流，通常围绕群组名称或非常高层次的主题领域。
所以，也许我建议的更不像 Slack，因为 Slack 似乎更像群组聊天，只是有更高级别的主题领域，而不是像帖子那样具体的主题。
1 个赞
我认为，也许只需在每个帖子下方的“回复”按钮旁边添加一个（返回？）“回复即链接主题”按钮，就可以满足一些对主题串的需求。仅当您想说一些只有对话中的某些人才会感兴趣的内容时，主题串（新主题）才有用。
另外，也许应该留下某种链接或提示，表明主题串/新主题已经发生。我们现在有这个，但不是在新主题拆分的地方。
因此，如果有一个回复帖子的链接主题，那么它将在回复图标工具栏正下方有一个链接，而不仅仅是 OP 下方的那个，但完全一样。
5 个赞
我认为我在主题帖里说过了。如果你想跟上一个活跃的讨论，主题帖简直是噩梦。你永远无法确定自己是否已经看到了全部内容，或者是否错过了重要的信息。主题帖只适用于已完成的、存档的讨论。我认为“回复帖子”中的每一个回复都应该在用户界面中显示，即使你是在回复正上方的那篇帖子（上次我检查时，这是设置中的一个选项，默认是“关闭”）。
2 个赞
我用过 Reddit 和其他有层级式讨论的社区，对我来说效果很好。我不喜欢为了继续阅读讨论而加载另一个页面，而且有些社区在几层之后就会这样做。而且我不喜欢当层级太深时需要水平滚动。而且我不喜欢当层级太多时它们变得太小。但有办法解决这些问题。我们现在有更多的经验了。
但是，每月有 20 亿人 使用 Reddit，其中 14 亿人使用评论系统。我没看到他们对此抱怨。
我用 Discourse 进行技术支持，效果很好！但我想有一个讨论论坛，而这正是我真正喜欢其他社区的层级式讨论的地方，我希望 Discourse 也能提供这个选项。正如我之前提到的，我会在可能的情况下提供帮助。
2 个赞
这正是我计划使用 Discourse 来驱动评论系统的一部分。如果表明对某条评论（而不是对整篇文章）的回复引发了新的讨论，那么相关人员将被提示将讨论转移到论坛上的新主题。指示新讨论何时开始的逻辑可以非常基础。例如，在对某条帖子进行两次直接回复后，下次有人点击该帖子的“回复”按钮时，将在帖子编辑器上方显示一个链接，方便他们开始新主题。参与“主题串”的其他参与者将被邀请到新主题。
在这种情况下，评论将像普通的评论系统一样在网站上生成。相关的讨论只会发生在 Discourse 上，但会从网站的评论中链接过去。
3 个赞
而所有这些都让主题讨论对我来说非常困难。这是无数个小问题造成的。
主要问题的解决方案是什么：在主题模型中，我必须定期滚动浏览整个讨论，以确保我没有错过任何内容？
我管理/版主一个小型的 FOSS 社区（3 个用户（包括我）比较固定，另外还有大约 6 个用户有时会参与，以及偶尔的临时访客），该社区运行在一个主题平台上。我错过讨论中不到一页的内容的次数真的让我对整个事情感到厌烦。
Reddit 依靠其巨大的势头和低进入门槛生存。它的阅读体验是互联网的“腋窝”。
2 个赞
这是你的看法，没关系。我喜欢主题帖。我相信我能解决用户不喜欢的问题。
如果插件 API 支持主题帖，我将努力添加一个插件，并免费提供该插件（如果需要前期资金支持），或者在需要财务支持时出售。我目前不了解 API。我以前做过开源和免费产品，有时它们也有构建或维护成本。
这很公平。你可以有一个“通知我此主题的更新”选项。有许多创新的解决方案。作为一名软件开发者，我经常从桌子的一边听到这些话，然后在另一边想出解决方案。但我不会因为某些部分的用户体验不佳而放弃整个应用程序。我设法改进那种体验。也许，也许主题帖不是答案，也许有其他答案，但在我看来，Discourse 的单一主题设计在像 Reddit 这样的社区中发现的多答案多评论讨论中并不总是像我希望的那样有效。
新的聊天主题似乎想解决这个问题，但它们是像 YouTube 那样的平面讨论，我听说它们不会被保存。在 YouTube 上，评论几条聊天主题后，就很难跟上。所以它们对我来说不是答案。
在 Reddit 或其他地方，会呈现一个主题，并围绕它形成多个讨论。在我看来，将这些讨论发送到单独的页面加载帖子并不容易阅读（加载页面，阅读，返回并重新加载过去页面 - 丢失位置，加载新主题帖子，阅读，返回并重复）。
1 个赞
你的意思是为帖子的每一条回复都单独发送通知吗？问题不是我不知道有新帖子，而是我不知道它们在哪里。如果有多个新帖子，我只能看到一个/最下面的那个。
Threaded content isn’t used everywhere because it facilities good discussion. It’s used because it turns a discussion into modular parts that can be sorted and hidden at the whims of a recommendation algorithm. And that’s a necessary requirement that allows a singular human user to interact with platforms that have massive amounts of content.
It works when you expect to only view a piece of content one time, letting you dig as deep as you want. But it’s complicated to untangle a web of discussions if you’re reopening and catching up on the same topic over and over, as you would in the setting of Discourse
2 个赞
@piffy，不过这对我来说不是这样。我从未觉得与层级式讨论互动比与扁平式讨论更困难，而扁平式讨论对我来说，一旦对话主题发生变化和/或超过 2 个人参与，在认知上就会变得困难。
2 个赞
我的观点更侧重于重新讨论同一个话题。假设有 12 条新回复。对于扁平式讨论，只有一个需要返回的点，你可以阅读所有 12 条。对于嵌套式讨论，可能有 12 个独特的对话线索及其回复，你必须在阅读新回复之前重新建立每个线索的上下文。
无论哪种方式，目标都应该是优化良好的讨论，而不一定是认知上的简单。毕竟，认知上最简单的选择是不参与讨论。
2 个赞
我觉得那样更容易。我不明白仅仅是缩进怎么会使阅读更困难而不是更容易。我会在我的文档中缩进每个标题，例如，https://stackoverflow.com/revisions/46690751/2#:~:text=Run%20code%20snippet-,expand%20snippet,-answered%20Oct%2011 所示。
那是一个 Logical extreme - Wikipedia. 根本不相关。认知难度，就像这里讨论的任何其他属性一样，具有不可忽略的 Benefit–cost ratio - Wikipedia
2 个赞
这不是关于缩进。这是关于这样一个事实：其中一个回复在一个8页的讨论的第2页上。你怎么知道你需要回到那里，你怎么有时间翻页/滚动到那个位置？
1 个赞
如果你要引用维基百科上的简单概念，你应该自己先读一下那个页面，因为它解释了为什么逻辑极端是一种有用的修辞手法。关键在于，一场好的讨论需要一定的认知负荷，所以它不应该是需要优化的主要变量。而且这也很主观，因为我个人觉得嵌套式讨论比单一线性讨论更难跟进。
主要问题在于，是扁平化的格式还是线索化的格式能产生更好的讨论。我不知道答案，但我的印象是，由于线索化的讨论通常会给你一个狭窄且精心设计的关于某个话题的视角，并且难以回顾，因此整体讨论质量会受到影响。但这却是大型平台不得不做出的必要权衡，所以你到处都能看到它。
这不是一个有用的逻辑技巧，因此引用了说明。另外，我随后解释了为什么它没有用，所以你为什么要求解释？
如果你之前澄清过这一点，我就不会提了。我同意，但既然没有人声称相反，我仍然不明白它的相关性。
我不认为这是需要解决的主要问题，因为用户可以选择以扁平格式还是线程格式查看讨论并不重要——每个用户根据个人喜好选择。所有回复都已在 GUI 下方进行线程化（这就是为什么除了线程底部有一个重复的蓝色回复按钮外，还有一个“回复”功能），所以这仅仅是将其暴露给用户的问题。
你指的是哪个 8 页的讨论？如果你描述的是一个假设的线程化和分页讨论，解决该问题的方法就是不分页线程。
什么不是关于缩进？
1 个赞
就我个人而言，我并不反对任何人制作插件来实现线程化或扩展可用选项。事实上，我认为社区 Discourse 插件的数量比应有的要少得多。
我所做的只是原则上同意 OP（楼主）引用的帖子，而且我认为线程化讨论不应该是 Discourse 核心团队应该投入时间的主要想法。
这在一定程度上是我喜欢它的原因。在书面材料的前面有大纲：
- 主题
- 标题
- 子项
- 标题
- 子项
- 标题
- 子项
- 标题
这是有组织的。你可以得到一个整体的视图，并轻松找到你要找的东西。
对我来说，现有带线程的讨论的缺陷是可用性/用户体验问题。
- 重新加载页面
- 丢失你的位置
- 查找或接收新评论的通知
- 深层线程（阅读空间更少）
这些并不难修复：
- 不要重新加载，打开一个对话框窗口或获取数据
- 不要重新加载，你就不会丢失你的位置
- 动态加载新评论或使用视觉指示器（粗体行）
- 随着深度的增加而减小缩进，或设置最大深度
确实如此。它不会取代已经很棒的社区体验，而是作为一种补充，用户可以切换（或选择启用）。
1 个赞