erlend_sh
(Erlend Sogge Heggen)
1
三年前，我们发表了一篇博文，讨论了 Discourse 和长篇论坛范式如何与短篇聊天范式共存：
这种工具组合是可行的，但存在一些缺陷。您将面临：
- 重复的用户目录
- 相互竞争的私人消息形式
- “这条消息属于哪里？”的不确定性
- 集成不佳的内容园艺工具
今年 HN 上被点赞最多的帖子之一 是关于论坛优于聊天的帖子：
第一段立即暴露了我们现在要解决的问题：
在尝试建立开发者社区一年左右后，一个热门观点是：如果你只能选择一个，那么在围绕开发者平台的社区建设中，请使用论坛软件而不是同步聊天软件。
社区建设者不应该被迫在两者之间做出选择，就好像它们是互斥的。这是一种错误的二元对立。短暂 vs 永久，短篇 vs 长篇；这些只是沟通的模式不同，效用上存在细微差别。它们仍然服务于与人沟通的完全相同的目的。
最低可行社区
让两个人一起进入聊天室，你就拥有了一个健康社区的开端。只要有定期的闲聊，这个房间就会显得活跃并吸引其他潜在的参与者。这是社区早期的一个很好的入驻策略，但它能扩展的程度是有限的。对于初创公司和新兴社区来说，做那些无法扩展的事情 可以是一个成功的策略；关键在于知道何时已经超出了最初的增长策略。
用户越多，你就越需要标准的（也是目前唯一可用的）Discourse 界面。但在用户较少的情况下，对于从零开始的初创社区来说，最大的障碍不是保持秩序，而是如何开始。我们确切地知道，在小规模的情况下，聊天效果更好。
换句话说，聊天解决了“有人说点什么！”的问题：
历史上，我们一直将 Day-0 社区推迟到聊天平台，并取得了相对成功：大规模的聊天社区通常会自然而然地发现需要一个比聊天信息流更结构化的补充，所以它们最终会找上门来。
这使我们能够专注于成为大规模讨论的最佳工具。然而，由于 Discourse 并非大多数新社区的首选工具，它常常处于一个非常艰难的境地，即成为一个额外的通信工具，在技术栈中更靠下。
向上移动技术栈
为了解决我们将 Discourse 引入已深陷聊天惯性多年的社区的棘手局面，我们开始着手一些相当激进的事情：
这个插件现在已在 Meta 的一个私有类别中启用进行测试。我们将在这个封闭的空间里进行聊天，这与 Discourse Chat MVP 将被引入现有 Discourse 社区的方式非常相似：员工聊天。
关于 Chat 的长期计划的一个复杂因素是，我们不可避免地要针对两个不同的市场：
（主要是私有的）团队协作聊天
（主要是公开的）社区聊天。
这两个垂直领域基本相同；解决一个问题也解决了另一个问题。无论您是启动一个团队项目还是一个社区，您都需要一个良好的 staff 聊天，以便您的主要利益相关者能够保持协调和社交联系。
早期访问
目前有两种方式可以试用 Chat：
-
在您自托管的安装中安装开源插件。虽然我们还不建议将其用于生产环境，但我们已经在内部团队实例以及 Meta 上运行了 Chat。
-
加入我们的私有聊天测试人员群组，以便在这里与我们一起在 Meta 上聊天。任何人都可以申请加入。我们也鼓励自托管用户在此分享他们的反馈。
Chat 将于 12 月下旬/1 月初在 Meta 上完全公开。
135 个赞
rmccown
(Bob McCown)
2
哦，非常好。这是我网站的必备功能，我目前有一个自定义插件来包装 Rumbletalk。将其作为 Discourse 核心的一部分将是一个绝对的加分项。
9 个赞
mattdm
(Matthew Miller)
3
这可能有点 为时过早，但——有没有考虑过桥接？
因为虽然我喜欢 Discourse，但我 最不需要 的是 又一个即时消息来源。在 Fedora 中，我们正在从 IRC 迁移到 Matrix。如果我们能桥接到 Matrix，这将非常有用……如果我们不能，那将是通信碎片化的错误方向。
15 个赞
太棒了。这将改变 Discourse 的普及方式。
8 个赞
erlend_sh
(Erlend Sogge Heggen)
5
计划进行桥接，尽管能力有限。我们正在研究如何为其他平台复制 @merefield 为 Discord 构建的内容。
14 个赞
mattdm
(Matthew Miller)
6
当然，从我的角度来看，_最_令人兴奋的是 Discourse 聊天能够充当 Matrix homeserver 和 Matrix 客户端，而不是拥有一个新的独立协议。但只要相对无缝，简单的桥接也可以。
8 个赞
嘿，有个小问题。这个插件是永久覆盖 Discourse，还是只在你选择的地方显示？也就是说，如果你选择安装它，你的整个社区都会改变，还是只在你选择的类别中改变？
4 个赞
meglio
(Anton)
8
恭喜发布第一个公开版本。
对于我们的山羊养殖户和奶酪制造商社区，我的长期总体规划是将一些只在 Facebook 上聊天的人转移到我们的 Discourse 社区。
对于我正在从头开始构建的专业 Jai 编程语言开发者在线社区，我的计划是展示 Discourse Chat 作为 Discord Chat 的替代方案。
对于我的一些仅使用 Slack 基本功能 的客户，我已经成功地将项目管理转移到了 Discourse，但一旦这个插件稳定到可供生产使用，我将开始提供它作为 Slack 的完整替代品。
最后，我宏大但几乎不切实际的计划是说服 Toptal 管理层放弃 Slack，完全转向 Discourse。Slack 在无法将知识组织成可搜索、可集体编辑、可分类、可关注的线程方面做得非常糟糕。
9 个赞
非常有趣的新闻，谢谢。
我的第一个想法是……是时候正式支持表情符号反应了？
我发誓我不是在开玩笑。
（是的，Discourse Retort 已经存在了。）
5 个赞
sunjam
(james.network)
11
我的建议。我还没有真正测试过该插件，但我发现这些比桥接（也很有用）更重要：
- 允许按群组访问聊天。
- 可选地允许匿名用户读/写访问聊天。
- 可选地按群组在 X 小时/天/周后删除聊天评论
- 可选地允许在聊天中显示标签/群组的侧边栏可见性
- 方便某人将评论“转换”为主题正文，可能通过信任级别/群组。可能通过标记处理。
- 将评论转换为现有主题的回复也会很棒，通过信任级别/群组。可能通过标记处理。
- 聊天中的标签
- 如果提到了允许用户加入/请求成员资格的群组，则允许该用户直接从聊天中加入/请求群组成员资格。
- 直接在聊天中联系 Discobot，公开或转换为私信。
- 分配聊天可见性以与特定主题/回复/标签相关联，持续一段时间
- 允许用户在聊天中快速提及现有帖子。
- 如果聊天中提到的帖子获得点赞，也为主帖子添加该点赞（假设支持此类操作，哈哈）
搜索主题/帖子集成
当用户尝试在聊天中发帖时，添加自动搜索会很有趣，这样当他们输入：嗨，我找不到音乐…… 他们需要的音乐帖子会自动显示为链接。
审核。
- 减慢在聊天中发布过多内容的用户的速度。
- 允许群组/信任永久忽略聊天中的用户/群组（一旦忽略，他们所有评论都将不再可见）
- 在聊天中标记/静音/禁止用户。
- 如果列入黑名单，则限制单词
- 允许按群组附加文件
任何鼓励他人加入或在更长的帖子中阐述的内容都将受到赞赏。
标签支持也将允许 聊天集成插件 支持，涵盖所有现有的 Discourse 桥接。
11 个赞
erlend_sh
(Erlend Sogge Heggen)
拆分了此话题
12
这太棒了！但正如其他人建议的那样，再增加一个即时通讯来源可能会有问题。虽然我喜欢 IRC，但我认为与 XMPP 集成会更好，因为它的联合网络更大。我不会选择 Matrix，因为 Matrix 的联合网络太耗费资源了。目前正在开发 Matrix 和 ActivityPub 以及 XMPP 和 ActivityPub 之间的良好桥接。
1 个赞
Jagster
(Jakke Lehtonen)
15
聊天使用分类的 slug 作为该频道的名称。这也许不是最好的解决方案？
3 个赞
meglio
(Anton)
16
我想重新定义这个问题。
出于某种原因，人们将此聊天功能视为一个额外的即时通讯来源。相反，我建议（在这个阶段）主要将其视为现有即时通讯平台的替代品，这些平台无法将知识组织成可搜索、可集体编辑、可分类、可关注的线程。
事实上，Discourse Chats不仅在功能上能够取代现有平台，还能消除旧平台，从而减少你使用的平台数量，而不是增加它。
因此，例如，如果你一直在使用Slack的基本功能（主要是简单的聊天），你只需停止使用它并开始使用Discourse Chat——现在你有一个平台可以考虑和集成，而不是一个。
对于Discord和其他“重量级”聊天工具也是如此。如果你只用它来做简单的事情，那么迁移到Discourse Chat并放弃旧平台会更好。这不仅会减少你使用的平台数量，还会使你的聊天与你的论坛/维基/知识库/文档/项目管理更紧密地集成。
另一方面，如果你一直在使用与Facebook紧密集成的Facebook Messenger，并且你需要它，为什么还要考虑开始使用Discourse Chats，从而增加一个即时消息来源呢？除非Discourse Chats能够与Facebook Messenger集成，并让你通过前者使用后者，即无需离开Discourse Chat，否则你不应该这样做。
Telegram、Viber等也是如此。
因此，我的建议是重新定义问题，并从不同的角度思考Discourse Chat功能。这是一个开始使用更少工具/平台而不是更多工具/平台的好机会。我从Discourse团队第一次提到Chat功能开始就一直这样思考。这实际上非常令人兴奋。
26 个赞
mattdm
(Matthew Miller)
17
这似乎只有在你谈论一个非常小的群体时才可能。我拥有 Slack、Matrix、Keybase、Telegram、Signal、Google Chat、Twitter、Discord、Mattermost 和 Rocketchat 仅仅是为了与同事沟通。更不用说 IRC 了，尽管 Matrix 桥接大部分解决了这个问题。哦，还有 Zulip。可能还有更多。这还不包括朋友、家人、爱好。所有这些都只是为了工作相关的沟通。
其中大多数“能够”取代其他大多数，但它们没有。相反，它们堆积起来。
众所周知……
注意括号中的内容，它直接提到了即时消息。这就是为什么我非常强烈地希望堆栈中的任何新东西至少能够相互通信——并且使用_现有_标准进行通信。
别误会我的意思——当然，可以尝试新东西。但对我来说，目前唯一真正引人注目的新东西就是互操作性。
10 个赞
meglio
(Anton)
18
除了与我试图传达的想法无关之外，一切都很好。也许我没有解释清楚。以后我可能会尝试用不同的措辞来解释。
4 个赞
jrgong
(jrgong)
19
@RGJ
言归正传：我认为将聊天集成到讨论社区是一个绝佳的主意。在我们的论坛中，我们最终只使用了 通过 Communiteq 集成的 Rocket Chat 中的一个频道，以及用于内部沟通的、关于一次性问题（没有长期价值）的频道。
我们之所以没有扩展，仅仅是因为聊天可能会：
a) 蚕食论坛的活跃度
b) 聊天最终会变成长篇讨论，而这些讨论更适合论坛
在我看来：我认为市面上有很多出色的聊天平台，如果社区有更复杂、更广泛的需求。因此，我希望看到一个更 KISS（保持简单）的聊天集成，它可以作为“私信 v2”，并最终取代当前的私信用户体验/用户界面。
8 个赞
