这是一个将 Slack 免费版用户迁移到 Discourse for Teams 的巧妙方法！归档 Slack 对话，然后爱上 Discourse for Teams。干得漂亮。
2 个赞
一篇帖子已合并到现有主题：Fig - iOS 原生 Discourse 客户端
一般来说：一旦 Salesforce、Oracle 或 IBM 收购了某个平台，就应尽快远离该平台。
9 个赞
Discourse for Teams 是个很棒的想法，从网站来看，其实现至少与这个想法一样出色。
我完全理解将其转为纯商业模式的决定，但我真心希望未来能有一个开源版本。我加入了很多 Slack 频道，这些频道无法负担付费方案，而所有现有的 Slack 开源替代品在功能和使用体验上都不够好，难以推动用户迁移。
我最近在这里不太活跃，但有趣的是，直到今天我才了解到 Discourse for Teams——尽管它已经推出好几个月了，而这正是我高度关注的内容。
6 个赞
你好，Helmi！很高兴看到你对 Discourse for Teams 感兴趣。这仍是一款相对较新的产品，所以如果你没有积极参与 meta 社区的讨论，或者没有在 Twitter 上关注我们，没听说过它也不奇怪！
Discourse for Teams 是基于 Discourse 构建的托管产品。如果你想自行搭建托管版的 Discourse，并将你的 Slack 社区迁移过来，当然完全可以这样做——Discourse 是开源的，并且高度可配置。不过，你也需要承担托管费用，以及为所有这些社区进行定制和运维的精力投入。
Discourse for Teams 的优势在于可以快速轻松地搭建站点，邀请团队成员加入并开展协作。我们还特意将其定价设定为让小型团队也能负担得起。因此，你完全可以与你的 Slack 频道讨论迁移到 Teams 的可能性。
欢迎随时开启免费试用。如果你希望就迁移 Slack 社区的具体事宜进行探讨，请随时私信我。如果你错过了，不妨看看这篇 Discourse for Teams 与 Discourse 的对比，了解更多详情。
7 个赞
谢谢，Tobias。来自邻县的问候 
感谢快速回复。我完全了解自托管实例的成本，也同意对于小团队来说，定价是公平的。不幸的是，团队规模往往更大（但仍然资金不足），这使得自托管开源方案与按用户计费的托管方案之间的成本差距迅速拉大。
但我真的不想反对这个定价模式。它非常公平，我相信你们会因此取得不错的成功。我一直缺少一个像 Slack 或 Discord 那样易于使用，但又更加有序和结构化的工具——这或许就是正确的方向。
我肯定会在未来的某个时候尝试一下。
6 个赞
15 个赞
你好，Discourse Teams 是否具备与“标准版”Discourse 相同的功能，仅仅是增加了 Teams 的视角和工具？还是说这是一个独立的版本？它能否与标准版 Discourse 协作？Teams 的 API 是否与标准版 Discourse 的 API 相同？例如，像 fibery.io 这样的集成工具能否像集成标准版 Discourse 一样集成到 Discourse Teams 中？
非常感谢。
2 个赞
你好，Holger！Discourse for Teams 基于 Discourse 构建，运作方式也基本相同。API 保持一致，现有集成同样适用。不过也存在一些差异，详情请参阅以下支持文章。欢迎立即启动免费试用，亲身体验。如有任何关于您具体使用场景的问题或反馈，欢迎随时通过 support@teams.discourse.com 与我们联系。
2 个赞
大家好，我们目前将所有内部沟通都集中在 Slack 上，但正饱受“Slack 病”的困扰：Slack 本应仅用于通知和“快速聊天”，但人们却倾向于用它处理一切事务，而其中许多内容本应更持久地记录在文档、Wiki 或问题跟踪系统等地方。对我而言，论坛式的沟通方式是一个很好的折中方案，它通过维持开放的讨论，使信息更加持久。Discourse Teams 似乎更能弥合这两者之间的差距。
我之所以询问 API 或集成方面，是因为尽管我们必须为 enterprise 客户提供符合正式 SLA 要求的工单系统支持，但我同样希望拥有一种更非正式的沟通和参与方式。在我看来，Discourse 实例或许能够提供这种支持。我们可能仍需为话题等设置权限系统，但总体而言，这应该是可行的。
对于更非正式的对话，我们也可以考虑基于聊天的互动式支持。然而，我们的讨论内容往往会超出聊天窗口的承载范围，随着滚动而消失，最终被遗忘。我们曾尝试让客户以访客身份访问 Slack 频道，但随着时间推移，聊天内容逐渐失效，难以回溯参考以进行有效的后续跟进。
现在我在思考，Discourse Teams 与内部 Slack 混乱局面形成替代关系，同时结合一个外部可访问的社区平台，这两者如何协同工作？甚至像 fibery.io 这样的工具，能否通过利用 Discourse 已原生支持的 API 访问，将这些要素全部串联起来？
希望这个用例能够被理解。
此致，
Holger
6 个赞
不错！我很欣赏你的思路。我们通常建议将 Discourse（或 Discourse for Teams）用作长期记忆库，而聊天工具则适合日常沟通和快速推进事务。因此，你目前的思路是正确的。
如果你已经拥有 Discourse 社区，或许可以考虑直接添加一些私密分类，用于内部讨论和文档共享。这比单独部署一个新的 Discourse for Teams 实例更简单、成本也更低。
目前我尚未见过有人通过 Discourse API 在彼此之间共享讨论内容，不过理论上这并非不可能。再次建议，你的团队或许更适合手动将需要长期保留的信息整理并保存到 Discourse 中。同时，团队也应从一开始就明确哪些内容应放入 Discourse，哪些适合放在聊天工具中。例如，我们将文档、待办事项以及无法立即解决的长期业务讨论都放在 Discourse 中。
fibery.io 看起来很有意思——我之前还没接触过。很期待了解更多关于它的信息，以及你们是如何将其与 Discourse 和其他应用结合使用的。
6 个赞
一篇帖子已被拆分为新主题：Discourse 是否支持将对话导出为有组织的批量数据？
你好，感谢反馈。我们能否使用 Discourse 搭建团队内部系统，同时向公众开放部分精选话题？
2 个赞
你好，Holger！能否再多介绍一下您的具体需求？您也可以通过 support@teams.discourse.com 给我们发送邮件。如果您对企业托管感兴趣，我们可以为您实现。
不过，正如 https://support.teams.discourse.com/docs?topic=85 中所述，标准的 Discourse for Teams 托管是完全私密的，访问主题需要登录。至少在目前，我们的重点是那些寻求用于内部沟通，以及与可以以访客身份登录的供应商或客户进行沟通的工具的客户。
如果对此类功能有足够的需求，我们未来可能会添加对 Page Publishing 中所述功能的支持。页面发布功能允许您将选定的主题发布为无需登录即可访问的页面。这能满足您的需求吗？
6 个赞
好的，目前访客登录功能可以暂时满足需求，因为受时间限制，我们尚未准备好进行公开的社区管理。
页面发布功能听起来也不错。
基于以上所有信息，我越来越能够理清整体架构。如果需要，我肯定会再联系您。目前，我倾向于将问题公开讨论。
4 个赞
我刚注意到 Discourse.org 网站上所有关于 Discourse for Teams 的提及都消失了。发生什么事了？
2 个赞
6 个赞