这确实满足了我关于委派审核活动的许多要求，因为类别将具有明确的范围（例如，全局审核员角色可能会有问题）。
我们愿望清单上唯一剩下的项目是，委派的审核员能够在其特定范围的类别下创建子类别。我们正在研究几种自动化类别治理的方法，或者至少使其自助服务，但如果可以的话，我更愿意将事物保持在同一上下文中。
在脑海中添加这个功能感觉很复杂。
我想检查一下这是否在考虑之中，或者如果我使用正确的设置组合，今天是否可行。如果不行，全局审核员/工作人员的手动类别创建或外部流程也可以，因为委派的审核员不应该一直创建类别。
您能提供一些关于您用例的细节吗？一个关于如何使用它的实际示例可能会有所帮助。
目前还不可能。限制类别创建给管理员（如果启用了“版主管理类别和组”设置，则还包括版主）的逻辑在这里：
如果该功能无法添加到 Discourse 核心代码中，我认为可以通过 Discourse 插件来实现。它需要在 can_create_category? 方法中添加一个额外的检查，以确保 parent 已设置，并且用户在 parent 类别中拥有版主权限。
如果插件不是一个选项，可以通过 API 来实现。本质上，系统用户将代表类别版主发出创建子类别的请求。这将相当复杂——对于您有一个外部网站作为 Discourse 论坛的 DiscourseConnect 提供者的情况来说，这可能是最简单的。
对我们来说，这与类别范围内的模组（mods）用例相同。基本上，通过群组为类别模组提供自主权，让他们可以根据自己的意愿维护他们社区的一小部分。
同意，感觉这可以添加到主代码库中，以增强类别模组模式，并且该函数是一个坚实的起点。我需要找到类别版主数据存储的位置，并在该检查中添加另一个 OR 条件。
然而，更复杂的更改（我认为）将在于 UI 本身，其中父级是必需的，并且他们是类别版主。我需要更仔细地查看代码，看看是更容易过滤父级结果以仅显示他们是类别版主的那些类别，还是触发一个验证案例，当用户是类别版主时，如果未选择父级或类别，则会出错。过滤将提供更好的用户体验，但验证模式可能更容易实现。
感谢您将此内容放入其自己的主题中。在我发布到公告后，我感觉它应该是一个独立的主题。
这感觉像是#员工体验，并且可能是一个很好的改进。我们有“三个规则”吗？
我记得@Julienlavigne在团队的背景下提出了这一点，即单个团队需要自主权，并且不应总是允许他们访问和查看彼此的类别。您是否仍然希望在Discourse中看到这一点？
这可能会很棘手，因为它需要仔细实施，并且需要一个新的管理员设置，因为大多数站点将不想/不需要将此委托给类别版主。此外，原则上我们不鼓励创建大量类别。
对我们来说，这更多是关于我们希望限制某些组的读取权限的类别私密性问题，但这可能会在以后实现。我同意，如果这确实会创建一种隐式类别管理员范围的角色。如果您创建子类别，那么该方希望能够调整读取等设置是有道理的。
我之前只考虑了创建活动，但是的，类别设置需要成为同一范围的一部分是有道理的。
谢谢，贾斯汀。这很有帮助。
您有多少个拥有类别版主的类别？您预计类别版主多久创建或修改一次类别？如果隐私不是问题，那么我不确定为什么您的类别版主不能直接请求版主或管理员为他们进行更改。
可能所有办公室的不同小组都会有 20-30 个顶级类别。每个小组将有自己的子类别结构。
并且 100% 肯定可以通过手动请求元类别或其他录入方式来完成。我设想每个顶级类别将有一到两名具有现有类别管理员权限的顶级版主。他们还将管理自己的类别版主团队，以帮助管理混乱并根据需要进行升级。
有些人对别人编辑“他们”的东西很敏感，所以如果我能有一个简单的隔离区，我会做的。顶级员工不会太多，所以我不想让周转变得停滞不前。一旦我们真正开始运作，我需要查看关于范围参与的报告，以确保人们感到被倾听，同时也要查看管理员级别的报告，以确保每个人都遵守计划。
是的。我希望类别版主成为其类别的管理员。这包括配置类别设置、权限，或者创建类别。我们已经通过 discourse API 自动化类别创建来解决了后者。
我不知道现在是否会有更多人想要这个功能，因为 Discourse 已经可以很好地支持更多分类了：
对我来说，我设想的是建立一个拥有可能超过 100 个国家/地区分会，以及其他类型分类的论坛。虽然标签也可以做到这一点，但我更喜欢每个国家/地区都能管理自己的子分类，而无需每次都手动请求管理员/工作人员，因为我认为分类管理比标签管理更能控制谁可以查看/回复/创建。