为什么你应该在公司/团队内部使用Discourse而不是Slack（4年使用案例）

赞美
1

我们使用 Discourse 作为主要的沟通、记录保存、研究记录和实验室日志工具四年多了。

我认为，与 Slack、电子邮件链和 WhatsApp 相比，大多数公司将从将 Discourse 作为其主要沟通工具中获益匪浅。

归根结底是这样的：如果您认为员工之间的对话对未来的反思有任何价值，那么您就需要 Discourse。
简单来说，基于频道的即时通讯应用程序（Slack 等）最适合进行即时对话，除非要查找非常具体的内容，否则没有人愿意回顾。它们倾向于将多个对话交织成一个长频道，其中包含数千行和数百个子对话。
相反，Discourse 本身就将对话分解为类别、主题和标签，这使得团队成员能够通过阅读 Discourse 主题作为日志来轻松了解特定主题、研究领域和相关对话，而不是试图从一个包含其他 6 个主题的对话频道中找出发生了什么，其中还混杂着每个人的午餐订单。
如果您的公司/团队/实验室从事任何形式的研发，我认为 Discourse 是必不可少的。

聊天 - 缺失的环节

并非所有对话都是信息金矿……事实上，许多对话都是日常事务，例如：咨询、提问、快速头脑风暴会议，这些会议不一定需要有自己的主题。更不用说“我遇到了这个 bug 和错误日志，谁知道这是什么意思？”或“我们今天午餐吃什么？”之类的陈述了。因此，Slack 必须保留下来，以便每个人都能快速有效地沟通。随着 Discourse 中引入聊天功能，所有形式的对话和讨论都可以集成到一个很棒的平台中！

我们的设置 - 快速安全

我们在 AWS EC2 上安装了 Discourse。在最初的几年里，我们是一个大约 5 人的小团队，所以 t3.small 绰绰有余。如今我们规模更大、资源更丰富，可以负担得起 m5.xlarge。
由于我们在运行 AWS 服务器，我们可以授予它访问 S3 存储桶的权限，因此可以轻松启用 S3 对象存储用于上传，从而安全地备份所有附件文件、图像、Excel 表格、CSV 文件和 PDF 文件。
我们启用了 安全上传，以保护我们的数据（我们将 Discourse 设置为仅限邀请模式，并拒绝任何未登录访问者访问论坛或文件）。
注意：我们当然忽略了使用 CDN 的建议，因为它会破坏安全上传的目的。

用于提高效率的插件

  • Assign → 将主题分配给人员是让团队成员负责某个工单/问题/项目的好方法。
  • Math → 如果您从事研究，您需要 LaTeX 和方程支持。
  • Reactions → 这只是现代沟通方式。我认为应该内置到 Discourse 中。
  • Shared Edits → 非常适合团队共享和编辑一些维基或其他知识/信息页面。
  • Whos Online → 在团队中，了解谁在线是必须的。
  • Footnote → 公司需要法律事务……这里是写保密条款的地方。
  • 值得商榷的是，Calendar 很有用，但它的实现方式和功能不适合我们。Topic Voting 是另一个可能很有用的选项。

主题组件：

  • Custom Header Links → 将公司/团队的重要链接放在标题上。我们有假期公告板、“我的任务”（用于 assign 插件）、指向我们 Jira 板的链接……

  • PDF previews + iframe Lightboxes → 同时安装这两个插件，并将 iframe origin domains 设置为包含您自己的域，这样上传到论坛的所有 PDF 文件都会显示在帖子中，并有一个按钮可以展开到全屏视图。PDF 非常非常有用，这样可以方便地共享它们。

  • Discourse Chat Sidebar → 将聊天带到前面，我们都使用 24 英寸到 27 英寸的屏幕，我们希望将所有 Slack/WhatsApp 的操作转移到 Discourse 中。

  • 值得一提的还有：
    ** discourse gifs，我认为它应该内置到 Discourse 中。
    ** Discourse Kanban，它不能替代 Jira，但有助于处理高级任务，并且与“assign 插件”配合良好。它只需要正确配置，而且配置起来并不容易。
    ** Sidebar Theme Toggle，我们只使用默认的暗/亮主题，因此可以轻松让用户选择他们的偏好。

结论

首先，感谢了不起且鼓舞人心的 Discourse 团队 :clap:
Discourse 是一个毫不妥协、坚如磐石、快速、安全的沟通平台，我希望更多的团队能受到启发，将其用于公司、大学实验室团队、初创公司等！

86 个赞
3

我很喜欢你关于如何使用 Discourse 的见解。这里有一个方便的 :loudspeaker: 呼吁其他读者，我们很想听听你们可能在内部使用 Discourse 的情况。这真的能帮助我们了解哪些方面做得好，并优先修复那些做得不好的地方。

我们自己也在内部使用 Discourse，所以听到我们的相似之处和不同之处（其实不多！）很有趣。

:writing_hand:t2: 正在记录——我们会考虑这些的，谢谢！

24 个赞
4

感谢您的见解。您让我开始思考传统的聊天组合——例如 Slack、Mattermost、Rocketchat，加上知识共享——例如 Confluence，与 Discourse 作为一个平台来处理所有这些事情。

既然您自己托管 Discourse 实例，您如何在手机上处理通知？我的理解可能有点过时，但在网络上，我们可以要求用户启用他们的浏览器发送来自网站的通知。在移动设备上，我认为除非 Discourse 实例由 Discourse 本身托管，否则不会向手机锁屏发送通知。您如何处理聊天回复/主题回复的通知，因为它们通常与时间敏感性相关？

9 个赞
5

我必须承认，此时推送通知是一个痛点。
内置的推送通知对 Android 和桌面用户（勉强）有效，但对 iPhone 用户无效。

在我看来，推送通知的问题在于，它们要到达用户那里有太多的障碍。你必须在 Discourse 的个人偏好设置中启用它，你必须在浏览器中允许它，你必须在 Android/Windows 系统中允许它。如果这三者中有任何一个阻止了通知，那么用户就收不到它们。就我个人而言，即使我积极想要推送通知，我也总是发现它们会在一段时间后停止。也许是因为浏览器更新？不知道。所以即使在 Android 上，我也不能说它真的像我希望的那样有效。

昨天我尝试了 Pushover notifications，该解决方案在 Android/Apple/Windows 上功能上有效，但有两个主要缺点（这就是我最终没有使用它的原因）：

  1. 它要求每个用户在手机上安装第三方应用程序，并将他们的 user_id 手动复制到 Discourse 的偏好设置页面 :grimacing:
  2. 通知会弹出，但它不会直接带你到 Discourse Chat/Topic，而是带你到 Pushover 应用程序，然后你可以再点击一次进入 Chat/Topic 的 URL。这听起来可能有点小题大做，但就直接消息通知而言，在推送通知消息和你想要去的地方之间添加一个网关应用程序会削弱体验。

Discourse 总是在不断改进，每天都有几十次提交，所以我仍然乐观地认为推送通知会得到改善。我理想的情况是有一个开源的原生 Android/iOS 应用程序，管理员可以自定义并提交到 Play/App 商店。但也许通过 OneSignal 等第三方合作会更简单，并达到相同的目的。

9 个赞
6

感谢您测试推送通知选项。我的看法也是如此，无论选项如何，都存在太多阻碍。这不是 Discourse 特有的问题，而是阻碍 Discourse 及类似平台被更广泛采用的问题——即通知和用户对通知的粘性。

4 个赞
7

我们绝对在考虑推送通知，棘手的问题是我们根本不想处理非我们托管的论坛的数据。

存在技术上的变通方法，我们可以说“嘿，手机，X 网站希望你刷新”，这可能会绕过这里的主要限制。也许有一种方法可以加密有效载荷，这可以解决这个问题。

如今，iPhone 上的 PWA（只要你不在欧洲）和 Android 上的 PWA 工作得相当好。但欧洲的变数让我们对应用程序进行了更多的思考。

17 个赞
8

我只赞同下面这一点

我发现 PWA 通知在 Android 上工作时效果很好，但这通常是少数情况，因为我注意到它停止工作需要多长时间。

2 个赞
9

我们最近进行了大量修复，我的 PWA 推送在我的手机上已经稳定了好几个月。我并不是说这已经完全解决了，但如果你的数据点是“我去年遇到了问题”，那么我强烈建议你再试一次。

话虽如此……苹果在欧洲扼杀 PWA 意味着我们必须解决这个问题，而且我们会解决的。

9 个赞
10

如果去年指的是 2023 年 12 月，那么这可能与时间吻合。很难知道它何时停止工作，因为缺乏通知并不是一个明显的信号。上次对我来说它停止工作是在 12 月和 1 月之间。

根据我目前的经验，它大约是 1 个月的通知周期，然后是 2 个月我没有注意到它们已关闭。然后重新开启它们以重新开始周期。我会再试一次，希望这次不会再发生。更大的担忧是我是我网站上迄今为止最大的高级用户。普通用户不像我这样关注这些事情。我敢打赌，此时只有一小部分人访问过通知设置一次以上。

我现在通过数据浏览器查看了一下，在一个每天有 450-500 用户访问的网站上，我有 30 个活跃用户拥有 push_subscriptions 记录。使用率约为 6%。其中三分之一的用户自 2024 年以来已更新。

我感谢在这方面所做的所有工作，并且我理解其中很多都取决于外部因素（即 Apple、Google）。但我只想表达我的观点，“运行良好”既不符合我的经验，也不符合 OP。

6 个赞
11

正如我们所知，现在情况已不再如此。

仍然希望 Discourse 成为 PWA 部署和推送通知霸权打击的标准！

9 个赞
12

还有一个 Tickets 插件，可以帮助更接近 Jira。

还有一个内联 PDF 预览的插件版本，如果我没记错的话，它也适用于移动设备。

1 个赞
13

我们使用 Discourse send PDF inline 并且没有收到任何投诉。

5 个赞
14

正如我回忆起来，您的插件也允许在移动设备上实现此功能。我还需要自己安装它。很棒的插件补充。

15

@Alon1 很高兴看到大家讨论内部社区，因为它带来了独特的挑战。特别是审核可能截然不同。不适宜内容和垃圾帖子几乎不在讨论范围之内，但取而代之的是主题相关性、清晰度和遵守保密要求的重要性。

我很想知道，你们做了哪些工作来确保主题质量很高？你们的审核团队是什么样的，让管理层理解这种必要性有多难？

5 个赞
16

感谢您提供这份非常有趣且有用的报告。

我的情况与您类似，使用 Discourse 来构建我的个人和组织虚拟基础设施。

我主要是一名独资创业者，有几个核心项目已持续数十年。因此，我需要工具能够即时启动新的路径、子项目（以及子子项目）和任务。

这些是写作和相关研究的集合。

我使用并测试了许多各种开源（以及付费——我不歧视）工具和平台，以提高效率和简洁性。

在过去的几年里，我发现 Discourse 和 Ghost 最常处于我各种工作流程的中心。

4 个赞
17

您提出了一个重要观点！\n\n每个论坛都有其围绕自身形成的文化以及随着时间推移形成的现状。\n\n当我在 COVID-19 疫情初期开始使用 Discourse 作为团队成员之间的沟通工具，以保存研究见解，比邮件链更好地跟踪对话等时，我想确保该工具被正确使用，至少按照我所理解的“正确”的愿景来使用。\n\n在我的情况下，这并不难，因为我们总共只有 7 个人，我可以亲自指导团队中的每个人创建主题，这些主题在主题上分开，但又不会在多个主题中重复相同的主题。回复的撰写都考虑到未来的价值（例如，你做了一个实验？描述它，提供背景信息，展示你做了什么以及如何做的，使用带有轴标签的图表……这样当你几个月后阅读这篇帖子时，它对你仍然有价值），将内容放入正确的类别，高效——用最少的词写出最多的信息，友善等等。\n\n一旦有了良好的核心文化，新加入公司的员工自然会以最少的指导来接受它。\n\n我仍然会偶尔与特定的人进行交流，讨论如何改进他们的主题和回复。这有助于维持良好的文化。\n\n总而言之，我相信如果你在公司规模小的时候致力于培养核心文化，那么随着公司的发展，这种文化会很好地扩展开来。

8 个赞
18

如果您有跨部门的讨论，但又不想让所有用户都成为其他部门群组的成员，该如何处理？或者也许您希望所有讨论都对所有人开放？在我的情况下，一些部门级别的讨论应该对其他人隐藏。

1 个赞
19

每个人都属于一个或多个组，我管理特定权限以访问特定类别。
虽然有两个类别对所有组都开放，但某些部门特定的类别仅对相关组可用。

一个人可以属于多个组的能力可以解决这个问题。您可以为跨部门员工设计一个组，同时将其主要组保留在其原始部门。

4 个赞
20

IMO，这是对内部社区最重要的决定之一，不应仓促做出。我们主要是一个内部开发者社区，所以我选择了一种基于工具的方法。仅此一项决定就打破了孤岛，同时也满足了信息安全办公室关于信息限制的要求。我们采取了与 @Alon1 相同的方式，让用户加入多个组——只需加入您感兴趣的工具的组即可。

我们还有一个平台范围的政策，禁止包含机密和项目特定信息——几乎所有问题都可以在不提及客户的情况下进行描述。

您是如何让管理层理解这一点的？即使向他们展示了失败的社区的例子，他们也无法理解问题的严重性，并认为这是吹毛求疵。到目前为止，我们一直拥有良好的文化，但管理层痴迷于不惜一切代价进行扩展。他们重视该平台固然很好，但他们不理解其价值来自于我们建立的文化——而这种文化目前正受到过快扩展的威胁，这是存在问题的。

我们面临的另一个问题是，每个人都想要自己的类别。对于任何考虑建立内部社区的人来说，要知道，对习惯了总是听到“是”的管理人员说“不”，是这项工作中非常令人疲惫的一部分 :sweat_smile:

4 个赞
21

确实，类别权限非常有价值。

一个部门可以有两个组，例如。一个组包含领导层（在某些类别中可能允许他们创建主题）。但也可以通过限制到特定组的标签组来做到这一点。

1 个赞