# 更新 Meta 上的分类组织方式 **URL:** https://meta.discourse.org/t/updating-how-categories-are-organized-on-meta/396306 **Category:** Site feedback **Tags:** meta-redesign-2026 **Created:** [2026年二月17日 17:03 UTC](https://meta.discourse.org/t/updating-how-categories-are-organized-on-meta/396306 "2026-02-17T17:03:32Z") **Posts on this page:** 1 **Showing post:** 10
### Author: ![stephtara](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephtara/32/517827_2.png) [@stephtara](https://meta.discourse.org/u/stephtara) #### Post date: [2026年二月18日 20:17 UTC](https://meta.discourse.org/t/updating-how-categories-are-organized-on-meta/396306/10 "2026-02-18T20:17:03Z")
> [@mcwumbly](#): > > 目前，我认为这种情况非常自然——某些标签在特定类别中积累到临界数量，人们开始看到这种模式并鼓励其蓬勃发展。 我明白你的意思——尽管它们隐藏在下拉菜单中，这使得它们的可见性远低于可以突出显示显示的子类别。 > [@mcwumbly](#): > > 有内置功能可以将标签限制在特定类别，或要求在给定类别中具有特定数量的标签，特别是来自给定标签组的标签，但我认为它们通常可能过于繁琐。 我稍后会回复你关于这一点，因为这是我计划广泛使用的一件事 😅（要求在给定类别中至少有一个来自给定标签组的标签），以避免子类别的倍增…… > [@mcwumbly](#): > > 我认为配置更多的是“一般支持” 我认为其中一部分是，但另一部分是“安装”的延续，所有的设置工作。是的，我现在安装了 Discourse，它具有所有这些非常酷的功能，我可以控制很多事情，但我如何根据我社区的需求来“塑造”它？这部分曾让我非常气馁，因为尽管所有的设置和内容都有文档记录，但我很难 a) 了解从哪里开始，以及 b) 了解如何将我对社区的“愿景”转化为设置和配置。 所以，我想的是围绕_初始_配置过程的额外一层。我认为 #Support（我不会将其重命名为“一般支持”，我只是用它来表明我的看法）更多地用于“我已经启动并运行了，或者我有一个需要解决的具体问题”，而不是“我已经完成了开箱即用的安装，现在我需要做什么才能让它为某种启动做好准备”。 说了这么多，我实际上认为“配置”作为管理员旅程的一部分是有意义的，而且它不完全等同于“支持”。 与我的社区进行类比——提醒我需要在适当的对话中提供有关该社区的新消息——如下所示：考虑到一位刚被诊断出患有糖尿病的猫的主人加入了我们的社区，我们如何组织类别？我现在决定的方式是“以会员为中心”，从“我刚到，这是什么鬼”（一些更礼貌的法语等价词）开始，然后是“我正在获取我需要的装备”，“我正在学习”——然后他们才准备好接受社区核心的真正“支持”。 如果我像这样考虑 Discourse，作为一个像我一样对所有事情都完全陌生的人，肯定有：1) 弄清楚我是要自己托管还是不托管，以及选择我的托管方式；2) 完成实际的安装 3) 设计我的社区并将其转化为 Discourse 配置。在这种情况下，需要区分 a) 我是从头开始构建，还是 b) 社区已经存在，我想迁移它——正如我在我的[Facebook 迁移挑战](https://meta.discourse.org/t/migrating-from-facebook-specific-challenges-and-some-thoughts/392562?u=stephtara)主题中所讨论的，我真的认为这改变了设置东西的方法。 这就引出了将迁移内容放在哪里。 > [@mcwumbly](#): > > 是的，这里可能隐藏着两个类别。如果我们从提议的嵌套结构的视角来看，也许应该将其拆分为更像 `support/migration` 和更像 `dev/migration` 的内容。 我还是会说，这取决于我们想讲述什么样的故事。Discourse 是想鼓励和促进现有社区迁移到 Discourse，还是更侧重于那些将从头开始使用 Discourse 构建的人？ 毫不奇怪，我认为关注迁移客户是有意义的，因为我确信那里有巨大的未开发市场。 在这种情况下，我希望“迁移”不要埋得太深。我个人会将其作为社区管理的一个方面（并重命名当前的社区类别，因为“社区”一词本身是模棱两可的，我最初以为它是“为 Discourse 社区”而不是“关于设计/构建/管理社区”）。标签还是子类别？可能至少应该有一个子类别。围绕迁移的脚本和技术内容是否应该放在另一个顶级类别中？ 或者也许迁移本身就是一个类别，其中包含有关如何调整和转换社区现有方面到 Discourse 的讨论，如何处理实际的迁移过程（实施），以及“数据迁移”。 --- _[View the full topic](https://meta.discourse.org/t/updating-how-categories-are-organized-on-meta/396306)._