是的，这听起来很对。我建议先只设置一个“离题”和一个“紧急”频道，然后看看情况如何。
别忘了，每个聊天也可以变成一个帖子（thread），这样那些火热的讨论就不会完全淹没在信息流中。
如果这类问题及其产生的讨论对长期来说很有价值，那么最好只设一个“离题”聊天频道，然后让这类问题进入特定的分类。我们在这里处理 Bug（错误）分类就是这样。它会受到密切关注。
2 个赞
我对你们的迁移计划很感兴趣。你们是否已经为此创建了一个新的主题？
1 个赞
还没有，我进展非常缓慢，设置工作远未完成，如果我能在一月或二月前有可以开始引导一些人加入的东西，我会很高兴的！（但如果事情出奇地快，我当然会在这里更新。）
在这个阶段，我真正卡住的一件事是，在以 discourse 为中心的新的生态系统中，我们给现有的 Facebook 群组什么位置。
3 个赞
别担心！一开始确实有很多事情要做。请随时向我报告您如何进行迁移。
在一个小得多的 Facebook 群组中，我们首先私下邀请用户试用 Discourse 设置。这帮助我们微调了一些设置和配置。
启动后，我们将两个系统并行运行了几个星期。我们非常努力地让在 Facebook 上发帖的任何人链接到 Discourse 平台上的相关主题和资源，从而带来更多流量。
在那初始阶段之后，我们发布了另一条置顶消息，其中包含指向 Discourse 注册的链接，以及一些关于总体参与情况的初步统计数据。
然后，又过了一段时间，我们要求在 Facebook 上的任何新帖子或回复都必须经过版主批准。我们发布了一条置顶消息，说明 FB 群组仅作为存档资源存在，所有当前的对话都在新平台上进行，以及我们在哪里发布了大量更新的文档和其他资源。对我们来说，这是推动用户切换平台的一个重要因素。
3 个赞
我对“在线客服”环境有点警惕。
我也是。在公司环境中，聊天可能还有点用处，比如作为社交的辅助渠道，或者问“今天去哪里吃午饭？”。但在支持或社区环境中，大多数人都是异步参与的，恕我直言，你警惕得有道理：为任何严肃的事情提供聊天可能会让人期望即时回复。它为帮助者增加了需要监控的渠道，并且需要管理开销，还需要将任何值得保留的聊天内容转换为主题。
你或许可以让聊天严格作为离题的闲聊流——或者你可以考虑不启动聊天，看看是否自然产生了需求。推迟引入某项功能比事后移除它（如果它变成一个麻烦）要容易。
4 个赞
我同意这里关于提供聊天支持的警告（而且当我加入 Discourse 时，聊天是我的主要关注点！）。
我认为它最适合用于闲聊。
聊天的另一个可靠用例是信任级别较高的成员之间。这可以帮助帮助者有一个地方可以互相支持，因为他们与社区的其余部分进行更公开的互动。
其中一种变体是社区团队本身——管理员和版主之间使用聊天进行相互协调。
4 个赞
我肯定计划从软启动开始，最少化的Discourse设置，志愿者/精挑细选的用户。我们还可能先迁移一些在Facebook上存在问题的活动类型：例如，我们的“初学者”小组被Facebook的技术问题拖累。所有与二手材料或在猫去世或进入缓解期时赠送剩余胰岛素有关的事情也是一个问题。所以这些是吸引人们进入的良好切入点。
我预计会并行运行这两个平台数月而非数周。是的，我确实考虑过在Facebook端增加“摩擦力”，使其在Discourse上发帖更具吸引力。
但问题是，我不认为以关闭Facebook群组为目标是一个好的策略。它规模大、活跃、非常显眼且排名靠前。所以我需要弄清楚如何将其转变为通往Discourse社区的门户，同时又不与Discourse社区竞争。
3 个赞
是的，这些绝对是我们在 Facebook 上的用例。我们有管理员群聊（不止一个，因为管理员团队相当大，人们感到不知所措，所以它被分成“新成员”、“版主”等），还有一个用于活跃帮助者的群聊，他们在其中互相支持，我们向他们“指导”最佳实践。
我最终不得不在某个时候为管理员团队创建一个秘密的 Facebook 群组，但现在它不再被广泛使用了。
如果我可以在 Facebook 上使用子群组，我绝对会想要一个“帮助者”子群组，因为我认为拥有一个比聊天中更持久内容的场所是有价值的。它也有助于讨论“正在进行的案例”，这些案例在繁忙的聊天中往往会随着时间的推移而消失在迷雾中。
谢谢！
2 个赞
我很高兴看到你们在这里元（meta）上公开地进行这次转型。许多其他人将从你们的经验中受益。
我真的很希望你们成功——如你所知，如果你们允许，我真的需要加入你们的社区，因为我家里有四只猫需要你们的帮助！
但我永远不想再回到脸书（Facebook）了。
不过，我认为你希望保持脸书（Facebook）的活跃是正确的。如果你也在其他地方有业务，你也希望保持那些活跃。找到平衡点不容易，但这是可能的。
戴夫（Dave）提醒我，你们的帮助者可以成为这其中的重要部分。如果你们中有足够多的人每天都致力于在你们的 Discourse 网站上与人交流，并提供那里每个人需要的东西，并且你们之间也只使用 Discourse 进行沟通，那么你们的 Discourse 网站就会获得关注。
4 个赞
哈哈，你知道吗，就在今天我还在想我应该邀请你过来看看，如果你愿意的话 
3 个赞
是的！
Stephanie - 如果你以后愿意把整个过程写下来，这可以成为一个很好的案例研究。
另外，一旦你开始配置你的论坛，我强烈建议保留一个按时间顺序排列的“开发日志”。它可以很简单，就是一个单独的文本文件。每当你启用一个功能、调整一个设置、更改一个权限时，都记下一个带日期和一些细节及关键词的笔记。将来当你疑惑“我是怎么让它实现这个的？”时，它会非常有用。
1 个赞
哎呀，太晚了！但这是个好主意！我已经不知道自己改了什么以及在哪里改了 
难道没有关于设置更改的自动内部日志或类似的东西吗？
我也不确定我做事的顺序是否正确：Discourse 安装目前不在正确的域名/子域名上，如果移动时一切都会中断，也许我应该先把它放在正确的域名上。
这就引出了一个棘手的问题：我应该使用哪个子域名名称，是使用子域名还是放在主域名上…… 
当然有！请看 管理员 → 安全 → 日志和筛选 (或 .../admin/logs/staff_action_logs)
也可以查看那里的筛选选项。
该日志会提醒您已经做了什么——但我喜欢用自己的话记录下来，包括我的想法。
1 个赞
今天我的想法是这样的：我是否应该采取与以往陷入过度工程化和优化一切的陷阱不同的方法来处理这件事。你可能会问为什么？因为我越是深入研究设置，越是在 Meta 上阅读，我就越容易陷入认知超载，并开始绝望地认为在……2027 年之前我永远也无法把所有这些事情整理清楚
所以，我对自己说，有没有其他的处理方式呢？
另一种方法是先几乎照搬 Facebook 社区的现有结构到 Discourse 上，然后以此为基础进行调整。我认为 Discourse 的一个巨大优势是其灵活性：需要一个新分类？创建它，然后你可以批量分配（如果我没记错的话）一大堆本应属于该分类但之前不存在的主题。子分类应该成为顶级分类？移动它。标签应该成为分类？转换它，如果不能转换，就创建一个新分类，我确信你可以将所述主题批量分配给它。想在特定分类中添加一个模板来约束用户？去做吧。
当我创建 Facebook 社区时，我已经非常熟悉 Facebook 群组的功能了（它们比 Discourse 的功能少得多）。因此，在第一批成员出现之前，我就能很好地设置好群组。
在这里，我有一批潜在的活跃成员准备进驻，但我对这个平台及其可能性还不够熟悉，无法在“启动”（即使是软启动）之前按照我希望的方式准备好一切，至少在感觉合理的时间范围内，以及以我现有的精力水平下是这样。
我在脑海中反复思考过各种想法，因此我有一系列可能的方案。我知道我擅长对眼前发生的情况做出反应，而且从精力角度来看（嗨，ADHD），这比提前规划一切要容易得多。Discourse 预设了很多很好的功能，所以也许我应该先信任它开箱即用的状态，同时知道当然会出现困惑，但我不会孤单一人，因为已经有了一个社区，其中一部分人肯定会站出来成为这次迁移的先锋。
而且我已经花了很多时间研究功能，确定需要做出的决定，尝试分类想法，评估哪些内容应该放在频道还是主题中，也许一旦真正的活动开始，前进的道路就会变得清晰。
有没有人采取过这种方法来迁移现有社区？
如果我走这条路，我会从以下几点开始：
- 欢迎/初学者 分类：用于新成员、入职介绍、基本问题：这将是我们 Facebook 初学者群组的“翻译”，它还将处理我们在主群组中进行的所有“欢迎”和“入职介绍”工作。
- FD 支持：这将复制我们的主 Facebook 群组，几乎所有的活动都在那里进行。
- 兽医：复制兽医群组，但我认为这将是最后一个迁移的，因为 Facebook 上的兽医群组完全可行（但随着更多兽医加入 Discourse，为他们准备好空间会很好）。
我会从非常宽松的设置开始，尤其是在标签方面——尝试鼓励用户标记主题。我已经确定了一组标签，这些标签将有助于我们随着社区在 Discourse 中的发展来构建社区结构，所以我们会先让这些标签可用，看看还会自然出现哪些其他标签。
随着时间的推移，我们可以开始在主分类中创建子分类（例如，用于悲伤支持、二手资料等）——随着时间的推移，我们将看到哪些有意义，以及是否需要在某个时候将它们提升为正式分类。关于如何更好地控制“成员旅程”的想法，例如“猫咪档案”或提出剂量建议的先决条件，可以稍后引入。
Messenger 的私下交流渠道可以原封不动地在 Discourse 中复制，我们可以实时“测试”创建相关的分类或群组消息。
这很有趣，因为今天存在的整个社区就是这样发展起来的。我从一些基本的东西开始，一些规则，随着它的发展和壮大，我们引入了新的东西。
所以，也许这也是迁移的方式。
我很想听听你们对这个“管理员的黑暗时刻”的看法、见解和经验 
1 个赞
对于大多数人来说，建议使用子域名。您可能希望将主域名保留给一个包含一些介绍性材料并链接到论坛、您的脸书页面等的登陆页面。
正如 Discobot 所说：
Discourse 可以安装在主域名（例如
example.com）或子域名（例如forum.example.com）上。虽然官方安装指南推荐使用子域名以求清晰和分离，但也可以直接在主域名上运行 Discourse。许多用户已成功在主域名上部署了 Discourse，尽管有些人会遇到 SSL 配置、邮件发送或 DNS 设置等方面的问题。
常见的子域名包括“forum”（论坛）、“support”（支持）、“community”（社区）——有时还有“ask”（提问）。
主域名实际上已经存在：https://diabete-felin.com – 一个博客和静态内容，复制了我们的一些文档，但我的计划是将文档集成到 Discourse 中。这使得我倾向于将 Discourse 放在主域名上，前提是我可以为已登录和未登录的用户在主页上显示一些类似博客的内容。但这在我脑海中还不太清晰。
由于我们是法语使用者，并且有很强的脸书倾向，这改变了词汇范围。我做了一项调查，得出了这些结果，但我仍在考虑使用主域名的想法。也许我应该尝试设置一个“博客”类别并对其进行样式设置，看看我是否能制作出一些类似于我“模糊愿景”的登陆页面应该是什么样子。
我在想我是否应该用不同于陷入我一贯的过度工程化和优化一切的陷阱的方式来处理这个问题……
你可能说对了一点
有人对现有社区采取了[渐进的有机]方法进行迁移吗？
是的，我从一个破旧的 Wordpress 论坛迁移过来的，方法是复制其结构并从那里着手。Discourse 一次性吸收起来会非常多，但逐步建立它是完全可行且有趣的。
距今多久了？那么社区的结构和组织是随着时间演变的吗？您介意分享一两个例子吗？
这里有几个关于创建自定义主页/登陆页面的主题，但有些方法相当技术性。如果你想走那条路，最容易上手的选项可能是 Discourse-home-page 插件 或 Landing Pages 插件。
但如果你将主域名分开，你将始终可以完全灵活地决定放在那里的内容。（我选择了一个使用 carrd.co 的登陆页面，我可以随心所欲地设计和修改它。）
当然！已经有几年了。冒着自我推销的风险……forum.TASAT.org 最初是基于 Wordpress 建立的，包含一些介绍性材料和两类科幻问答：“挑战”（Challenges）和“狂野推测”（Wild Speculations）。我迁移了这些内容和现有的帖子，并对主题进行了适当的标记。
我立即创建了一个群组（Group）和一个私人分类，用于我自己和几个虚拟账户进行实验。（一个 TL1 用户和一个版主，以便体验这些视图。）
对基础知识感到满意后，我就开放了论坛。此后的一些发展如下：
- 我很快看到了添加一个“万能的、非问答”分类的需求，于是添加了“观察甲板”（Observation Deck）。
- 我为几位热情的初始用户创建了一个“咨询委员会”（Advisory Council）群组，并为该群组提供了一个私人分类，以帮助集思广益制定策略。
- 一个想法促成了“评论”（Reviews）分类的添加。
- “开发日志”（DevLog）分类对 TL1 用户可见。没有人会看这个——但假装有人可能会看而写下内容，这迫使我清晰地记录更改。
- 我逐渐添加了一些插件，例如 Gamification，以及主题组件，例如 Category Headers、Unanswered Filter 和 User Card Directory。
- 我继续关注新主题，如果用户没有添加标签，我就会添加标签，并在需要时创建新标签。
到目前为止，所有与 Discourse 相关的事情都进行得非常顺利。更大的挑战是如何扩大受众。听起来你不会有这个问题 
2 个赞