你们两位用清晰且信息丰富的帖子，让这个话题看起来像教程的开头。 
我写了这么长的回复，是因为我一直在思考如何规划新论坛的搭建。所以我想拿你的问题做个实验，看看能否整理出一些方案，并看看你是否觉得这有用。
我同意考虑使用标签（tags）而不是把所有内容都塞进分类（categories），我自己在一些私人论坛里就是这么做的。但你需要注意，目前分类有两个明显的优势：
- 分类对于控制访问权限至关重要
- 插件允许对分类进行更多的自定义
你可以看看 Is anyone else using tags on a Discourse forum in a big way?
新的标签功能 目前正处于频繁开发中，这将使标签的使用变得更加容易。其中包括：
这里的关键问题在于，你的哪些需求应该作为分类来处理，而不是标签。但我们不必一开始就做出决定。我们先设计那些功能较重的分类，然后再看看哪些可以转换为标签。
决策过程
设计分类有多种方法。当不考虑将标签作为主要机制时，我会按照以下步骤进行：
- 需要哪些分类？
- 哪些分类需要单独的用户访问控制？
- 我现在还需要默认分类吗？
这里采用的路线与通常不同，因为你可以看到最少的默认分类，这些分类可能允许你通过标签完成其他所有操作。
- 我需要默认分类吗？
- 哪些分类需要单独的用户访问控制？
- 还需要哪些不需要用户访问控制的其他分类？
A. 总体需求是什么？
首先，用于开发论坛结构的社区理念是什么——社区和论坛是不同的。
从你的第一篇文章中，我可以看出你的社区有以下需求：
- 主要目的是 支持
- 支持 由 产品 驱动，即没有产品就没有客户，也不需要支持。
- 支持 按 客户状态 细分，即客户与非客户
- 产品 还有额外的 功能请求 ——来自客户和非客户
论坛的额外需求是：
- 部门 管理 产品，但客户/用户通过 产品 进行交互
备注：
- 支持可能由部门管理，但客户/用户可能更关注他们使用的产品。因此，除非你的部门是品牌或子公司，且客户和用户在日常交往中几乎只认同这些部门，否则我不会通过包含你的组织结构来使论坛复杂化。
- 我在这里使用 客户，因为对 VIP 的使用应有保留意见。它消除了后来创建 VIP 子客户组的可能性。我曾在面向社区专业人士的论坛中见过这个问题，因此我会将 VIP 保留用于进一步的细分。
B. 实现总体需求所需的最小分类有哪些？
1. 我需要默认分类吗？
我认为所有默认分类都是必不可少的，但你可能不需要。只需注意，默认设置是经过大量考虑，以满足平均论坛所有者和论坛用户的需求：
-
#lounge（休息室）
默认情况下，这是针对信任等级 3 (TL3) 用户的。我建议将其保留为你最活跃的非客户的 奖励。你可能会 tempted 通过重命名它并降低访问所需的最低 TL 来将其用作 VIP 分类。不要这样做：保持你的 VIP 组和分类与默认组和分类分开。
-
Contribute > Site feedback（贡献：站点反馈）
供所有用户提出改进建议或指出论坛中的问题。
-
#staff（员工）
供管理员和版主使用，大多数用户不可见。
-
Uncategorized（未分类）
默认设置为 允许未分类主题。
你可能希望禁用 抑制未分类徽章 设置，以使此类主题在主题列表中更显眼，从而更有可能被分配到更相关的分类。
- 这会给版主和高 TL 用户增加一点工作量，但对于无法决定分类的新用户来说，这会容易得多。
- 此分类是默认的
共享草稿分类，这也是保留它的一个原因。
示例
此时，你的最小分类将是：
- Lounge（休息室）
- Site Feedback（站点反馈）
- Staff（员工）
- Uncategorized（未分类）
2. 哪些分类需要用户访问控制？
唯一确定的需求是：
你想将用户和客户分开，因此必须使用分类来实现这一点。任何其他方法都会非常痛苦。
这意味着你需要将客户和非客户分别放入单独的 Group（组）中，其中至少有一个分类满足：
- 客户拥有 CRS（创建、读取、查看）访问权限
- 非客户仅拥有 S（查看）访问权限。
示例
此时，你的最小分类将是：
- Customer（客户）
- Lounge（休息室）
- Site Feedback（站点反馈）
- Staff（员工）
- Uncategorized（未分类）
3. 还需要哪些不需要用户访问控制的其他分类？
你的需求是：
即使没有你的需求，目前的结构看起来也相当不足，因为不清楚产品支持请求应该放在哪里。因此，你至少需要一个产品支持分类，而这又需要一个 Customer（客户）子分类。我会保留一个高级 Customer（客户）分类，用于处理仅与客户共享且可能仅对客户可见的问题。
你可以使用 功能排名插件 对产品功能请求进行排名。这是通过对分类中的主题进行排名来实现的，因此你至少需要一个分类。然后，你可能有两种选项来按产品显示排名：
- 一个通过产品标签过滤视图的分类。
据我所知，这 可能是一个阻碍，但我还没有尝试过。
- 每个
Product（产品）分类下有一个 Feature Request（功能请求）子分类
无论选择哪种选项，将 Feature Request（功能请求）主题放在子分类中都会更容易。
没有单独 Product（产品）分类的示例
此时，你的最小分类将是：
- Customer（客户）
- Lounge（休息室）
- Site Feedback（站点反馈）
- Staff（员工）
- Support（支持）
- Customer（客户）
- Feature Request（功能请求）
- Uncategorized（未分类）
有单独 Product（产品）分类的示例
此时，你的最小分类将是：
- Customer（客户）
- Lounge（休息室）
- Product 1（产品 1）
- Customer（客户）
- Feature Request（功能请求）
- …
- Product 100（产品 100）
- Customer（客户）
- Feature Request（功能请求）
- Site Feedback（站点反馈）
- Staff（员工）
- Uncategorized（未分类）
现在出现了产品与使用者之间关系的问题。
| 问题 |
Support（支持）的一个分类 |
每个 Product（产品）的一个分类 |
| 大多数/所有客户是否使用大多数/所有产品？ |
是 |
否 |
| 大多数/所有客户是否与单个产品相关 |
否 |
是 |
| 核心 Discourse 中哪个支持更好 |
标签功能更有限 |
分类有更好的支持 |
| 插件中哪个支持更好 |
标签功能更有限 |
分类有更好的支持 |
| 分类管理是否更容易 |
是 |
否 |
| 视图和报告管理是否更容易 |
否 |
是 |
| 对新的 Discourse 用户是否更容易 |
否 |
是 |
总的来说，我认为你应该为每个产品使用单独的分类，因为这样可以工作，主要缺点是分类视图过长，以及在设置分类和子分类详情以及组访问权限时会度过一段无聊的时光。
有单独 Product（产品）分类的示例（如上所示）
此时，你的最小分类将是：
- Customer（客户）
- Lounge（休息室）
- Product 1（产品 1）
- Customer（客户）
- Feature Request（功能请求）
- …
- Product 100（产品 100）
- Customer（客户）
- Feature Request（功能请求）
- Site Feedback（站点反馈）
- Uncategorized（未分类）
4. 还有哪些其他分类可能有用
我相信你知道你可能想要但未在此处指定的其他分类，例如：
- 公司文档，例如适用于所有客户和产品的通用条款和条件
- 产品文档，例如与产品相关的文档
- 下载，例如与产品相关的软件，如旧版软件产品本身
- 操作教程
- 常见问题解答（FAQs）
C. 哪些功能应该是标签？
至于你应该使用哪些标签，我需要更多信息，例如部门如何管理支持。
起初，我会将 部门 排除在你的论坛之外，因为你可以根据 Product（产品）开发报告，并提供按 部门 的摘要，这不需要任何可见的标签。
我在这里引用现有的话题，让你了解在支持论坛中可以使用标签做什么。这些话题按从新到旧排列：
还有一些有用的插件：
以及一些有用的主题组件：
