企业官网建设流程全解析

• 文档

本篇围绕 Rust 官方 RFC 仓库中 non-goals.md 展开，完整解析 RFC 3392（领导理事会 Leadership Council）明确划定的五类"非目标"，并结合主文档 3392-leadership-council.md 的条款说明每条非目标背后的取舍逻辑与例外机制。读完后，你能理解这份 RFC 如何以"明确不做哪些事"来约束治理结构的权力边界，以及"非目标"这一文档结构本身在大型设计文档中的作用。

一、背景：non-goals.md 在 RFC 3392 中的位置

RFC 3392 的目的是建立取代核心团队（core team）的领导理事会（Leadership Council）：理事会把大部分权力下放给各顶层团队，自己保留由该 RFC 明确划定和限定的一部分决策权（见 3392-leadership-council.md）。为控制篇幅，主文档将若干非约束性参考材料拆分到独立子文档中，"本 RFC 的非目标"正是其中之一：

3392-leadership-council.md#L64-L70 中的 "Reference materials" 一节列出了四个拆分文档：完整动机 motivation.md、非目标 non-goals.md、方案论证与替代方案 alternatives.md、以及理事会初始工作建议 initial-work-of-the-council.md。

要理解为什么需要理事会，先看 motivation.md 给出的问题清单：当一项决定不清楚属于哪个团队的职权（purview）时怎么办？没有明确归属人负责人的重要但不紧急的工作由谁负责？当工作无人推进、组织债务累积时谁来担责？历史上核心团队同时承担了"识别这些工作"和"亲自做这些工作"两件事，而经验表明这两件事放在同一个团队里都负担过重，导致结果不佳甚至成员倦怠（burnout）。non-goals.md 就是在这一背景下回答：为了建立理事会，本 RFC 明确把哪些事排除在外。

以下逐条继承 non-goals.md 的原文内容并展开。

二、非目标 #1：不制定理事会的完整政策与程序

原文：

Laying out the complete policies and procedures of the Council. While the RFC lays out and bounds the structure of the Council, the Council's full policies and procedures will be created by the Council itself. It is also expected that the Council will change and adapt to meet the needs of the Rust Project as it evolves.

也就是说，本 RFC 只建立并限定理事会的结构，而理事会的完整政策和程序将由理事会自己制定，且预期理事会会随 Rust 项目的演进而改变和适应。

这一条的设计理由可以从主文档的配套机制中得到印证：

• 主文档要求理事会"公开且默认"运作，至少每季度发布一次面向公众的活动通报，并以其"职责、期望与约束"清单为标尺自我评估；每年必须向所有有意愿、有能力的 Project 成员征集理事会是否有效履职的反馈，并在允许积极参与的论坛中公开讨论（3392-leadership-council.md#L484-L486）。这为"理事会自己制定并持续修订政策"提供了可执行的检查回路。
• 主文档的 "Feedback and evaluation" 一节规定：所有政策决定都应带有评估日期，初次评估期短于后续评估期；运行良好、少需改动的政策可延长评估间隔，刚被调整或被质疑的政策应缩短评估期（3392-leadership-council.md#L325-L327）。这正是"结构由 RFC 固定、程序由理事会演化"能够持续迭代的基础。
• 拆分文档 initial-work-of-the-council.md 则从"交接清单"角度呼应了这一非目标：临时领导层明确把大量元层面的流程决策（理事会何时何地开会、同步/异步决策流程、决策模板、透明记录规范、backlog 追踪工具、外部请求处理流程、代表交接程序等）推迟给新理事会自行决定，理由是"避免把某一种特定结构钦定下来，而是把决定权交给未来实际使用这套结构的人"。

另外，alternatives.md 的 "Broader governance changes in this RFC" 一节给出了更直接的原则陈述：作者组强烈认为，凡是能推迟给理事会的都应推迟，本 RFC 应聚焦于定义和限定理事会本身及其与项目其余部分的交互；同时他们也判断，在 RFC 提出的结构就位之后，后续的渐进式演化会更容易。

三、非目标 #2：不解决所有治理问题与潜在治理关切

原文：

Addressing all governance and potential governance concerns. One of the Council's responsibilities will be to identify and reflect on the issues present in governance, but we see the formation of the Council as part of a continuous process of improving Rust's leadership and how it meets the needs of the Project.

即：识别和反思现存治理问题是理事会自身的职责之一，因此本 RFC 不试图一次性解决全部治理关切。作者把理事会的设立本身视为"持续改进 Rust 领导层及其满足项目需求方式"这一连续过程中的一个环节。

这一条与 motivation.md 中列出的失败模式清单直接对应：无人担责导致决策悬而未决、非紧急工作长期不做、需要跨团队协调的结构性投入难以由个人推动、有动机的个人承担了缺乏结构性支持的工作进而倦怠。RFC 选择为这些已知类别提供结构性答案（识别、优先化、委托、问责机制），但不承诺为所有当前尚未暴露的问题预置条款——这与非目标 #1 共同构成"RFC 管结构演化、不管内容填充"的一致立场。

四、非目标 #3：不成立额外团队（唯一例外：Launching Pad）

原文：

Forming additional teams. The focus of this RFC is to form the Council and does not include the creation of additional teams, subteams, or groups of any kind.

We recognize the importance of having additional teams, but see this as outside of the scope of this RFC. Instead, it will be the responsibility of the Council to investigate and understand such needs and then create additional teams to ultimately handle these issues.

This has one exception, other than the Council itself: the "launching pad" top-level team, which provides a temporary grouping of teams not yet attached to any existing top-level team either directly or indirectly.

本 RFC 只负责成立理事会，不包括创建任何额外的团队、子团队或任何形式的群组；成立新团队是理事会的责任。但除理事会本身外存在一个例外："launching pad"（发射台）顶层团队，它为尚未直接或间接挂接到任何现有顶层团队的团队提供临时归属。

主文档对这一例外给出了完整定义（3392-leadership-council.md#L153-L166）：

• launching pad 是一个伞形团队（umbrella team）：没有直接成员，只有子团队代表；
• 理事会应设法为它的每个子团队找到或创建更合适的父团队，随后迁移子团队；父团队已存在但暂不接纳子团队时，launching pad 可作为过渡住所；
• 被移除或被重组掉的团队，其子团队若未被明确安置，也默认进入 launching pad；
• 理事会必须每 6 个月审查 launching pad 的子团队归属，确认进展；与其他顶层团队一样，若理事会认为其不再必要，launching pad 也可以被退役，退役流程与其他顶层团队相同；
• 理事会未来可以给它自己的 purview，但主文明确这不在本 RFC 范围内。

这一例外的存在理由在主文档中也有说明：Rust 项目中的所有团队最终必须隶属于至少一个顶层团队，launching pad 确保"所有团队在理事会上都有代表"（3392-leadership-council.md#L122）。RFC 发布时的初始顶层团队列表为：Compiler、Crates.io、Dev tools、Infrastructure、Language、Launching Pad、Library、Moderation、Release（3392-leadership-council.md#L138-L149），主文档同时声明该列表"并非最优集合"，建议理事会的首要工作之一就是梳理治理结构、修正顶层团队集合。

alternatives.md 的 "Launching pad alternatives" 一节还补充了边界设计的另一面：作者考虑过给 launching pad 增加更多 purview（如参与团队组织与结构、最佳实践、流程制定），但因本 RFC 已经破例创建了一个新团队、且团队人手配置本身就令人担忧，故不再增加复杂度；理事会未来可以自行改变它的 purview。

五、非目标 #4：不改变现有团队的章程或职权范围（两个例外）

原文：

Altering the charters or purviews of existing teams. While this RFC does discuss membership in the Council, it does not extend beyond this to update the charter or purview of any existing team. Existing teams continue to follow their existing charters and purviews.

This has two exceptions:

• the core team: As part of this RFC, all of the capabilities and responsibilities of the core team move to the Council and are then clarified, modified, and constrained by the rest of this RFC.
• the moderation team: As this RFC covers topics like conflict resolution and Council oversight, it does define additional capabilities for the moderation team, as well as additional checks and balances providing bidirectional oversight between the moderation team and the Council.

即：本 RFC 只讨论理事会的成员构成，不借此机会更新任何现有团队的章程或 purview——现有团队继续遵循各自的章程和 purview。两个例外分别是核心团队与调解团队。

例外一：核心团队的全部能力转移到理事会

主文档 "Relationship to the core team" 一节（3392-leadership-council.md#L228-L234）落实了这次转移：

• 领导理事会在所有方面作为核心团队的继任者；外部实体或流程中出现的 "the Rust core team" 指代，由理事会在该意义上承接；
• 核心团队目前持有一些 Project 账号的凭据（infrastructure 团队同样持有）。由于理事会预期不需要这些凭据，它们不会从核心团队转移给理事会，而是仅保留在 infrastructure 团队手中——infrastructure 团队负责在安全与可维护性之间平衡地保障各团队的工作访问权限，理事会可通过政策协调哪些团队应获得访问。

主文档脚注 [^core] 还澄清了一个术语细节：Rust 的 "core team" 并不像某些其他开源项目那样指决定技术方向的团体，Rust 把决策权分散到对各自 purview 负责的众多团队，这也是本 RFC 停止使用 "core team" 这一术语的原因之一。

例外二：调解团队获得额外能力与双向监督

因为本 RFC 涉及冲突解决与理事会监督，它同时为调解团队（moderation team）定义了额外能力，并建立了调解团队与理事会之间双向的监督和制衡。主文档中可对应到以下机制：

• 临时调解人（contingent moderators）：调解团队必须始终维护一份公开的临时调解人名单，由调解团队与理事会通过内部共识决策共同批准，双方各不少于三人；临时调解人不能属于当前调解团队或理事会，须被广泛信任、有资质胜任调解与审计工作，并愿意随时接手临时调解（3392-leadership-council.md#L548-L553）。
• 审计机制（audits）：若理事会成员认为某项调解决定未遵循调解团队的政策和程序，可发起审计；审计由临时调解团队配合调解团队进行，重点核实"是否按既定政策与程序行事"，而非重新评判调解决定本身；审计报告必须在不泄露任何私人信息的前提下向调解团队和理事会汇报（3392-leadership-council.md#L567-L586）。理事会可以要求审计，但不得推翻调解决定或调解政策。
• 最后手段问责（last-resort accountability）：在极端情况下，理事会可以一致决议同时解散自己与调解团队；反之，调解团队在成员不少于三人时也可以一致决议同时解散自己与理事会。随后顶层团队重新任命理事会代表，临时调解团队成为新的临时调解团队；被移除的代表与调解人至少一年内不得再担任相应职务（3392-leadership-council.md#L588-L602）。
• 调解团队本身不可被理事会移除，理事会未经调解团队同意不得改变其 purview（3392-leadership-council.md#L172），这进一步限定了"例外二"是单向增权而非理事会可任意改写的条款。

六、非目标 #5：不确立理事会的完全不可变属性

原文：

Establishing completely immutable properties of the Council. Any aspect established in this RFC can be modified in the future, via the public policy decision-making process, with oversight provided by that process. This RFC lays out policies for making such changes, and the processes of changing such policies must follow the existing policies.

即：本 RFC 确立的任何方面，未来都可以经由公开的政策决策流程修改，且修改过程自带监督。本 RFC 规定了做出此类变更的政策，而这些政策自身的变更流程必须遵循现有政策。

主文档提供了落实这一非目标的具体条款：

• 理事会被明确预期会"演化"（3392-leadership-council.md#L108 的Evolve期望：理事会需随团队、项目和社区的需求演变而演变）。
• 涉及理事会形态的实质性变化必须走公开决策流程，目前即 RFC 流程：该流程必须要求代表同意（明确同意或无异议）、允许代表提出阻止性异议、提供合理的公开评估与讨论时间、提供向理事会反馈的清晰路径，并且提案在生效前有最低反馈延迟，任何代表可要求将反馈期延长至至多 20 天（3392-leadership-council.md#L401-L414）。
• "修改这份列表（或本 RFC 本身）"被明确列为必须经公开提案的决策示例之一（3392-leadership-council.md#L416-L424）。
• 这里遵循的正是 Rust 项目一以贯之的 RFC 流程——该流程由 0002-rfc-process.md 确立，旨在为进入语言和标准库的新变化提供一致、受控的路径，使所有利益相关方能确认演进方向。

因此非目标 #5 与其他四条共同构成一个自洽的体系：结构现在定、程序后来定（#1）、问题持续解（#2）、团队慢慢建（#3）、职权默认不动（#4）、条款皆可改（#5）。

七、"非目标"章节的文档工程价值

从仓库中这份 non-goals.md 与 alternatives.md 的配合方式，可以看出 RFC 3392 的写法本身也是一种值得借鉴的设计文档实践：

1. 范围控制：non-goals 把"明确不做"写进正式文档并给出例外清单，使读者不必猜测边界。例如"不成立新团队"看似一刀切，但 launching pad 例外被明确标注并限定为"临时归属"，避免了执行时的歧义。
2. 例外即接口：五条非目标中三条带有例外（#3 的 launching pad、#4 的 core team 与 moderation team、#5 的修改流程）。每个例外都指向主文档中可查证的具体条款，例外因此成为读者深入主文档的导航锚点。
3. 与替代方案论证呼应：alternatives.md 对"是否在本 RFC 中做更多治理改动"（对应非目标 #1、#3）、"是否引入选举/公投/不信任投票"（对应非目标 #2 的延续性立场）逐条给出了取舍理由。non-goals 回答"不做什么"，alternatives 回答"为什么不做别的"，两者互为镜像。
4. 可审计的遗留交接：initial-work-of-the-council.md 把被推迟的工作以公开清单形式移交给理事会，其中明确声明"这些都不是有约束力的建议，理事会可以自由设定和优先化自己的议程"——这与非目标 #1 的"政策程序由理事会自定"完全一致，保证了"不做"不等于"遗漏"。

八、结论

non-goals.md 篇幅不长，却是理解 RFC 3392 权力分配逻辑的关键：领导理事会获得的是被这份 RFC 逐项限定和约束的决策权，而政策程序、额外团队、现有团队职权、治理问题的完整答案，都被有意留在理事会成立之后的公开决策流程中处理。对阅读 Rust 治理文档的开发者而言，这份文档展示了治理类 RFC 的典型结构——先用动机（motivation.md）说明为什么需要理事会，再用非目标划清边界，用主文档（3392-leadership-council.md）规定结构、决策与问责机制，最后用替代方案（alternatives.md）和被推迟工作清单（initial-work-of-the-council.md）保证边界之外的部分可追溯、可交接。简体中文参考译本见 Leadership-Council-RFCzh-Hans.md（注意：权威版本为英文版）。

• 文档