提交

只有组织可以访问提交授权申请的页面。 对公司组织申请的审核将被优先处理。

批准标准

1. 命名空间不能是像 tool 或 apps 这样的通用名称。
2. 命名空间应大于三个字符。
3. 命名空间应正确且清晰地标识保留所有者。
4. 组织应积极使用命名空间。
5. 应该有证据表明，*不*保留命名空间可能会对社区造成歧义、混淆或其他损害。

非公司组织将代表以下之一

• 拥有许多包的大型流行开源项目
• 积极发布包的大学
• 积极发布包的政府组织
• 积极发布包的非营利组织/非政府组织，例如 Our World in Data

一般而言，审核人员对申请未使用的授权的公司组织应该更加宽容。

例如，虽然将命名空间授予具有新产品线的初创公司或现有公司是合理的，但将命名空间授予没有太多用户的社区项目并不合理。

拒绝

被拒绝的申请将根据批准标准收到关于决定的明确理由。 由于命名空间过于通用而被拒绝的申请将被内部保留供未来审核人员参考，试图保留之前因该原因而被拒绝的命名空间的新申请将显示警告。

接受

当一个申请被接受用于由组织外部的项目使用的命名空间时，将向这些项目的拥有者发送电子邮件，通知他们新的授权。 该电子邮件将包含指向 命名空间页面 的链接。

根授权

每个批准的申请都会为组织获得一个根授权。 此授权可以生成任意数量的 子授权。

子授权

根授权 的所有者可以在任何时间创建子授权，无需批准。 与此类授权关联的命名空间必须是根授权命名空间的子命名空间。

子授权不能有自己的子授权。

命名空间页面

每个活动授权的命名空间都将有自己的页面，其中包含其 开放 状态、当前所有者、授予所有权的时间以及与命名空间匹配的项目总数等信息。

项目页面

每个项目的页面（示例）与活动命名空间授权匹配，将指示前缀是什么（NuGet 目前没有这样做），并将作为药丸或标签突出显示。 此值将与 命名空间详细信息 API 中的 prefix 键匹配。

单击命名空间将把用户带到 其页面。

视觉指示器

对于与活动命名空间授权匹配的项目，用户将能够快速确定以下哪种情况适用

1. 与 授权所有者 关联的项目将没有视觉指示器，用户应该只依赖始终存在的首缀。
2. 未与 授权所有者 关联且匹配授权 开放 的项目将有一个独特的指示器，不会传达不信任或危险。 一个好的选择可能是来自 Font Awesome 的 用户 图标或来自 Google Fonts 的 组 图标。
3. 未与 授权所有者 关联且匹配授权受限的项目将有一个独特的视觉指示器。 当项目在授权创建之前就已存在时，这种情况就会出现。 指示器将传达不真实性或缺乏信任。 一个好的选择可能是警告标志（⚠）。