我明白你的意思——尽管它们隐藏在下拉菜单中，这使得它们的可见性远低于可以突出显示显示的子类别。
我稍后会回复你关于这一点，因为这是我计划广泛使用的一件事 
（要求在给定类别中至少有一个来自给定标签组的标签），以避免子类别的倍增……
我认为其中一部分是，但另一部分是“安装”的延续，所有的设置工作。是的，我现在安装了 Discourse，它具有所有这些非常酷的功能，我可以控制很多事情，但我如何根据我社区的需求来“塑造”它？这部分曾让我非常气馁，因为尽管所有的设置和内容都有文档记录，但我很难 a) 了解从哪里开始，以及 b) 了解如何将我对社区的“愿景”转化为设置和配置。
所以，我想的是围绕初始配置过程的额外一层。我认为 Support（我不会将其重命名为“一般支持”，我只是用它来表明我的看法）更多地用于“我已经启动并运行了，或者我有一个需要解决的具体问题”，而不是“我已经完成了开箱即用的安装，现在我需要做什么才能让它为某种启动做好准备”。
说了这么多，我实际上认为“配置”作为管理员旅程的一部分是有意义的，而且它不完全等同于“支持”。
与我的社区进行类比——提醒我需要在适当的对话中提供有关该社区的新消息——如下所示：考虑到一位刚被诊断出患有糖尿病的猫的主人加入了我们的社区，我们如何组织类别？我现在决定的方式是“以会员为中心”，从“我刚到，这是什么鬼”（一些更礼貌的法语等价词）开始，然后是“我正在获取我需要的装备”，“我正在学习”——然后他们才准备好接受社区核心的真正“支持”。
如果我像这样考虑 Discourse，作为一个像我一样对所有事情都完全陌生的人，肯定有：1) 弄清楚我是要自己托管还是不托管，以及选择我的托管方式；2) 完成实际的安装 3) 设计我的社区并将其转化为 Discourse 配置。在这种情况下，需要区分 a) 我是从头开始构建，还是 b) 社区已经存在，我想迁移它——正如我在我的Facebook 迁移挑战主题中所讨论的，我真的认为这改变了设置东西的方法。
这就引出了将迁移内容放在哪里。
我还是会说，这取决于我们想讲述什么样的故事。Discourse 是想鼓励和促进现有社区迁移到 Discourse，还是更侧重于那些将从头开始使用 Discourse 构建的人？
毫不奇怪，我认为关注迁移客户是有意义的，因为我确信那里有巨大的未开发市场。
在这种情况下，我希望“迁移”不要埋得太深。我个人会将其作为社区管理的一个方面（并重命名当前的社区类别，因为“社区”一词本身是模棱两可的，我最初以为它是“为 Discourse 社区”而不是“关于设计/构建/管理社区”）。标签还是子类别？可能至少应该有一个子类别。围绕迁移的脚本和技术内容是否应该放在另一个顶级类别中？
或者也许迁移本身就是一个类别，其中包含有关如何调整和转换社区现有方面到 Discourse 的讨论，如何处理实际的迁移过程（实施），以及“数据迁移”。