我有一个客户希望托管一个单一的品牌社区，其中包含三个子社区。
有人成功做到过吗？Groups 还是 Categories 更适合？
子社区需要拥有独特的品牌、不同的成员体验，并利用不同的特性和功能。
所有三个社区将由同一个社区经理或团队管理。
我很想听听你们是如何做到的，并希望看到任何你们愿意分享的示例。
6 个赞
您需要创建 3 个群组以用于权限目的。然后，您需要创建 3 个类别来代表 3 个“子社区”。
例如：
创建：
群组 1
群组 2
群组 3
然后创建：
类别 1（用于群组 1）- 类别安全权限为：“群组 1 创建/回复/查看”
类别 2（用于群组 2）- 类别安全权限为：“群组 2 创建/回复/查看”
类别 3（用于群组 3）- 类别安全权限为：“群组 3 创建/回复/查看”
2 个赞
这将需要单独的论坛。
3 个赞
为了补充 @ondrej 的观点，您需要每个社区 2 个组。成员组，其授权管理员是成员组的所有者。然后您需要您的社区经理组，该组也将是类别版主。
如果自托管的 Category Restricter 插件可用于扩展类别版主和全站版主的能力。它增加了在某个类别中禁止用户发帖的能力。
因此，您需要一个主站团队来协助进行全面暂停和全面禁言。
2 个赞
您期望这些子社区之间发生什么样的互动？
我想到的一些问题包括：
-
是否希望一个社区的成员能够自由地参与到其他社区中？
对他们来说，这应该感觉像是一个更大的社区吗？还是当他们参与一个社区与参与另一个社区时，感觉像是完全不同的社区？ -
是否希望一个社区的对话能够延伸到其他社区？
例如，您是否期望或希望鼓励大量交叉链接讨论，或者在一个对话中引用另一段对话的内容，等等？或者您认为这种行为不太可能发生，不值得鼓励，甚至应该被阻止？ -
您能否分享一些您期望每个社区使用的不同特性和功能的例子？
我可以想象到您可能有一些不同的想法，但任何能帮助进一步说明您想法的例子都将非常有帮助。
7 个赞
很棒的问题 
您希望一个成员能够自由地参与其他成员吗？
不，一个成员从一个社区加入或参与另一个社区的可能性非常小。
您希望一个社区中的对话能够跨越到其他社区吗？
不，不会有任何交叉。它们是完全独立的主题，有不同的目标成员。
您能否分享一些您期望每个社区使用的不同功能和特性的示例？
- 一个单一品牌登陆/主页，有三个链接指向独特的社区
- 翻译插件
- 单点登录 (SSO)
- 主题 (Topics)
- 私人小组 (Private groups)
- 能够轻松地在一个社区中复制另一个社区的功能
- 可能需要一些开发工作，让成员能够自行选择他们想成为三个社区中的哪一个的成员
- 社区经理能够对所有三个社区或根据需要对一个社区进行更改
- 一个社区的分析中心（最初） Creating an Analytical Hub using Categories, Approval Process and Upvoting
4 个赞
很有意思。
其中一些让我怀疑是否最好将它们保留为三个独立的站点。这个选项被排除掉了吗？如果排除了，为什么？
我的想法是——到目前为止，似乎将所有这些站点合并到一个站点下的动机是为了方便管理团队。但也许有其他方法可以解决这个问题。对多个社区应用配置更改感觉像是一个技术问题，可以通过其他方式解决，而将它们分开可以为每个社区提供更大的自由度，以便在确定每个社区有不同的需求时（随着社区的发展，这些需求可能会进一步分化）以不同的方式做事。
另一方面，我看到一些例外情况，与我所描述的情况有所不同：
一个单一的品牌登陆/主页，有三个指向独特社区的链接
这为什么重要？
如果这些社区中的人们彼此完全分开，那么谁会从在一个地方看到所有这些社区中受益呢？
也许这里的答案会带来一些我迄今为止错过的关键见解。
再说一遍，我觉得这可以通过其他方式解决。如果它只是一个带有三个链接的主页，也许会动态地拉入一些内容，这可以在站点之外实现。
现在，说了这么多，如果重新审视以上内容感觉没有帮助，并且已经决定所有这些都应该合并到一个站点下，我们可以回到你最初关于如何做到这一点的疑问，同时牢记你迄今为止分享的内容作为背景。
1 个赞
这真的很有帮助，戴夫，我很感谢你的反馈和建议！
目前，我们正处于探索阶段——试图弄清楚我们希望这些社区（从会员、社区经理和组织的视角）如何运作。在此阶段，没有什么是不可能的。
你提出了很多有趣的观点，我也有一些问题想问我的利益相关者。
我将在此展示我学到的东西，并获得那些澄清问题的答案。一旦我有了清晰的认识，我将回到这个帖子。我很高兴能找到最佳方法 
3 个赞
您能多分享一些关于这个的信息吗？在收到此帖中提供的有益建议和问题后，我决定为我的客户提出两个选项。
- 单个站点，多个社区
- 多个站点
探索单一站点设置的主要原因是让一位社区经理能够管理所有三个站点。这不是出于成本考虑。
3 个赞
我建议初期采取精益方法。
我的意思是，也许可以先为特定的用例设计具体的解决方案，付诸实践，然后进行迭代。也许它会演变成一个为社区团队提供的功能齐全的跨社区仪表板，或者“足够好”的东西比这要小得多。
例如，社区经理可以首先使用 Discourse Hub 来查看所有三个社区的动态，并了解何时每个社区都有需要处理的未处理标志。
更进一步的步骤可以是使用其中一个社区的聊天频道作为“主基地”，并配置来自所有社区审查队列的通知动态，以协助跨所有社区进行审核。
对于指标和报告，可以从指向每个社区管理界面区域或数据探索器报告的书签集开始，这是一个简单的起点。
更进一步的步骤可以是使用 Discourse Automation 设置一个 AI 生成的报告，该报告将一些数据从该社区内的不同来源汇总到每个社区的 PM 中。这仍然是三个独立的 PM，但需要去的地方更少。
再进一步的步骤可以是使用 AI 个性化工具从跨社区获取数据，以从跨社区的数据构建单个报告。
我认为许多构建块已经存在，虽然使用它们来拼凑东西可能看起来需要更多的工作，但这也是一个构建所需内容的绝佳机会，并优先考虑哪些部分应该更快地到位，哪些可以稍后处理。
如果所有这些都被证明是有价值的，并且需要更多功能，那么可以构建更定制化的东西，例如自定义插件，并更有信心地确保它能带来期望的结果。
3 个赞