短链接 (fuchsia.dev/go) 旨在长期使用、具有有意义的名称以及应被大众关注。这些链接经久耐用且使用扁平化的命名空间，因此您应仔细考虑每个提案，以限制创建的短链接的数量。
在批准待处理的短关联请求时，审核人员应考虑以下因素：
提议的链接能否长期使用？ 链接应具有持久性，因此您应该有充分的理由相信，链接能长期持续吸引大众关注。
正例：常规 Fuchsia 常见问题解答页面或当前受支持硬件的列表。虽然主题会随着时间的推移而变化，但它们将始终具有相关性。
反例：正在考虑的 RFC 提案。虽然该提案当前具有相关性，但会被接受或拒绝。如果 Google 接受了此主题，它可能会是一个可供参考的合适短链接主题。
链接是否涵盖一般主题或概念？是否面向广泛的受众？
正例：
- FIDL 概览。这是 Fuchsia 使用的基本技术。
- Fuchsia 安全模型。这无论是用户还是开发者，都很感兴趣。
反例：
- 单个系统调用的文档。指向系统调用列表的链接会更相关。
- 有关如何通过以太网启动特定型号的 NUC 的说明。如需更广泛地了解在各类设备上启动 Fuchsia 的更宽泛页面，您可以提供指向更宽泛的页面的链接。
链接是否复制了不太可能更改的现有易于使用的链接？
- 正例：
不太可能更改，因此 可能是多余的。
- 正例：
链接名称是否具有意义？它是否符合“尊重代码”政策？ 短链接当然应该简短，但不得以易于理解为代价。
正例：这两个示例都很简短，具有描述性：
/docs/go/faq（呈现为 fuchsia.dev/go/faq）。/docs/go/hardware-specs（呈现为 fuchsia.dev/go/hardware-specs）。
to链接是否指向/docs/目录内的文档？正例：
to: /docs/concepts/software_model.md。
反例：
to: http://google.com/。