文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载导读RFC 1728north star RFC是 Rust 项目在 2016 年提出的一套年度规划与报告机制以问题陈述problem statement为年度主线通过团队级目标goal、六周发布周期里程碑release cycle milestone和年终回顾报告retrospective三层结构把分散的社区贡献拧成一股绳。阅读本文后你将完整理解这套机制的术语体系、时间表、标签约定R-problem-statement/R-goal与落地形态并能对照本仓库中 20172021 年的历届路线图 RFC、以及 2024 年后的 Project Goals 新流程看到它如何实际塑造了 Rust 的治理方式。背景为什么 Rust 需要一颗北极星1.0 之后的大问题RFC 的 Motivation 部分开门见山Rust 1.0 之前项目有一个清晰、单一的目标——把 Rust 做完并交付给世界。那个时期虽然紧张但整个社区围绕同一个使命团结一致。1.0 是一个独特事件此后项目的努力开始变得分散而成功恰恰依赖于在越来越广泛、越来越复杂的维度上持续改进。副作用是更难凝聚力量、更难讲清一个故事最终也更难发布ship。现状的三个具体痛点RFC 指出1.0 之后社区曾在 internals 论坛和博客上尝试列出一些重大目标并取得过诸如 MIR 这样的标志性成功但整体存在三个系统性问题缺乏系统的进度跟踪与沟通连最投入的社区成员都难以判断各项工作处于什么状态更不知道如何参与。典型症状是MIR 什么时候落地?稳定化的阻塞项是什么这类问题被反复提问。应该提供一个一眼可见的视图展示 Rust 当前的战略优先级及其进展。好想法太多、优先级不明大量有前景的 RFC 在队列里滞留数月各子团队却各自聚焦自己的战略目标造成不必要的摩擦和势头损耗。应该就优先级达成共识并传播出去让所有人朝大致相同的方向使劲。缺少类似 1.0 的发布汇聚点快速发布流程带来了极其稳定可靠的产品但反过来也降低了按时发布新功能的压力。应该在保留快速发布的同时建立一个围绕它凝聚社区、打磨产品、形成清晰公共叙事的焦点。RFC 强调这份提案只做增量改进不对 Rust 团队施加过多额外负担也不试图套用某种特定的项目管理结构。核心设计总览一年一个完整规划周期RFC 的核心循环如下年初9 月用不超过一个月的时间通过 RFC 流程与全体社区共同确定一小撮年度问题陈述产出当年的north star RFC年中每 6 周一个发布周期各团队围绕问题陈述设定季度目标在 issue 跟踪器上以R-goal标签跟踪并按发布周期里程碑汇报年末8 月左右撰写年底发布产出面向公众的回顾报告retrospective作为全年的rallying point——既是 Rust 的国情咨文也是一次向世界展示成果的宣传炸弹publicity-bomb。这套机制要达成的三个主要成果是通过共识决定项目级目标以公开路线图的形式传播这些目标用一份信息量充足的回顾报告庆祝成就。术语体系四个关键概念RFC 用一节专门定义了贯穿全文的术语理解它们是掌握整套机制的前提术语含义problem statement问题陈述对 Rust 面临的某个重大问题的描述可能横跨多个团队与多个专业领域。每年由项目共同决定作为全年决策的广泛基础收录在当年的 north star RFC 中并在 issue 跟踪器上打上R-problem-statement标签。goal目标由各团队按季度设定服务于解决项目已识别的问题。目标带有预估截止时间那些以稳定特性为结果的目标还带有预估的发布版本号。目标可在 issue 跟踪器上继续细分为离散子任务并打上R-goal标签。retrospective回顾报告年末交付的面向公众的报告以强化年度叙事的方式呈现每个目标的推进结果展示新特性、披露有趣的技术细节并表彰为达成目标、解决问题做出贡献的人。release cycle milestone发布周期里程碑所有目标都有完成预估并被放置到与 6 周发布周期对应的里程碑上。里程碑按时间段计时但不代表某个具体版本——为当前 nightly、当前 beta 所做的工作甚至不直接影响某个具体版本的工作都归入工作完成时段对应的发布周期里程碑。问题陈述与 north star RFC为什么以问题而非方案为导向规划工作是**问题导向problem-oriented**的。虽然聚焦怎么做看似理所当然但实践中人们很容易沉迷于某个具体技术方案而丢失更大的上下文。通过把动机放在顶层优先位置可以确保团队聚焦在正确的问题上并对解决方案保持开放心态。对问题空间达成共识能够框定后续对方案的讨论避免意外与情绪摩擦也为未来的决策留下清晰的因果记录。数量与节奏810 个、严格一个月每年不超过一个月决定当年的一小撮问题陈述数量以能在社区中可管理地呈现同时足以支撑所有团队一年的主要工作为准810 个是合理参考规划通过 RFC 流程进行对全体社区开放产出即当年的north star RFC严格限时是为了避免无休止的 bikeshedding——这些活动不是项目的主角应当高效完成然后回到实际工作。问题陈述的输入来源包括社区年度调查the survey与生产用户外联production user outreach以及开放讨论过程。虽然最终产物是问题导向的讨论中自然也会触及可能的解决方案——在承诺解决一个问题之前至少要对方案在设计上和资源上的可行性有基本判断。问题陈述的书写格式每个问题陈述由一句话概括加**一段或几段详细描述含重要性论证**组成。RFC 给出的示例性句子包括Rust 编译器对紧凑的编辑-编译-测试循环来说太慢Rust 缺乏世界级的 IDE 支持Rust 的异步 I/O 故事非常原始Rust 编译器错误难以理解Rust 插件没有清晰的稳定化路径Rust 与垃圾回收器的集成不佳Rust 的 trait 系统未能完全支持零成本抽象Rust 社区多样性不足Rust 需要更多培训材料Rust 的 CI 基础设施不稳定在人们想支持的平台上获取 Rust 太难真实流程中每一条都会配以一段或多段论证。由谁负责推进**核心团队core team**负责发起流程在 internals 论坛或直接在本 RFC 仓库并负责合并最终 RFC——因此也负责确保讨论在截止时间前收敛到合理结论问题陈述确定后在 rust-lang/rust issue 跟踪器上为每条创建一个 metabug 并打上R-problem-statement标签每个 metabug 的 OP 中由相关团队维护各自目标列表并链接到跟踪 issuenorth star RFC 与其他 RFC 一样并非不可变年度中途若出现新的动机可以修订甚至追加问题陈述但项目不应反复重开整个 RFC。目标设定与进度跟踪每个 6 周发布周期内做什么解决方案在常规的 6 周发布周期中成型并执行每个周期团队要设定服务于年度问题的具体目标并回顾、修订此前目标具体用什么论坛与机制做评估和目标设定留给各团队自行决定、自行实验但最终结果是每个发布周期、每个团队都以标准格式记录其目标与进展一个目标描述的是为解决年度问题做出贡献的任务可能涉及具体交付物也可能不涉及可以被进一步细分。并非团队在季度内做的所有工作项都算目标——目标只需细化到足以展示在持续解决项目问题即可服务于季度目标的工作仍以子任务形式在 issue 跟踪器上跟踪但只需归档不必作为目标直接汇报到路线图上。R-goal标签与目标书写要求每个目标都要在 issue 跟踪器上建一个 issue打上R-goal标签。目标本身必须满足用一句话概括结果或交付物尽可能清晰明确带有子目标/子任务的目标必须在 OP 中以标准格式列出它们。每周期必须做的 triage每个周期各团队必须对自己名下的所有R-goal与R-unstableissue进行 triage 并更新以下信息子目标与子任务集合及其状态所属的发布周期里程碑。里程碑指派规则很可能在本周期或下一周期完成的目标指派到相应里程碑预期在遥远未来完成的目标不必指派里程碑。发布周期里程碑的多重用途发布周期里程碑对应一段 6 周的时间窗包含该时段完成的工作。它不对应某个具体版本指派到它的目标也不需要在某个具体版本中以稳定特性落地。它的用途不止于本 RFC 的目标跟踪还包括R-goal跟踪R-unstable与R-RFC-approved特性的稳定化跟踪关键 bug 修复跟踪。虽然里程碑是时间导向的、不严格绑定到单个即将发布的版本但从所赋值的R-unstableissue 集合中可以推导出即将在后续版本中落地的新特性清单。周期末报告每个发布周期的最后一周各团队撰写一份简述其周期目标进展的报告由某位项目成员汇总所有团队报告发布到 internals.rust-lang.org。这些报告除了提供进度可见性外还将作为后续版本发布公告release announcements的素材来源。回顾报告年末的 rallying point回顾报告是向世界展示 Rust 及其社区最佳一面的机会本质上是state of the union国情咨文式交付物其核心目的有三在 Rust 世界制造对重大事件的期待**激励rally**贡献者朝着既定目标前进制造一场大规模PR-bomb向世界展示成果。在内容与形式上回顾报告需要做到覆盖过去一年 Rust 的全部活动面向广泛读者贡献者、用户、非用户逐个回顾当年应对的问题与为之达成的目标同时突出更广泛社区与生态的重要工作对上述两者都提供如同原始文档primary documentation一般的技术细节——这是向世界展示最好一面的场合用清晰的文字和充足的示例深入讲解新特性并将它们在主题上串联起来示范如何写出前沿的 Rust 代码一如既往慷慨地表彰贡献者并在其中着重庆祝那些推动项目战略利益即年初定义的问题的具体个人诚实评估绩效是否取得进展是否彻底解决了某些问题哪些地方没达标、明年如何改进由于回顾报告必须是高质量文档且覆盖大量素材预期需要大量的规划、编辑与修订其具体工作机制在 RFC 写作时留待后续确定。如何呈现路线图三种载体与分层渐进细节经过上述流程一年的 Rust 路线图被编码为三种相互关联的载体并随时间演进north star RFC——把当年全部问题陈述集中在一处R-problem-statementissues——承载各个问题陈述每个都链接到支撑它的目标R-goalissues——承载工作项层级用元数据标签标明其状态。单独看这些载体构成路线图的原始数据raw data任何人都可以对全部R-problem-statementissues 执行一次 GitHub 查询通过逐层挖掘得到一份相当准确的路线图快照。例如is:issue label:R-problem-statementRFC 同时指出要让流程成功路线图必须以**醒目、简洁、分层渐进细节progressive detail**的方式呈现。早期的一个原型视图rust-z曾作为参考实现存在具体呈现方案留待后续设计。时间表为问责制而精确设定RFC 刻意对事件时间做了精确规定以建立清晰预期与问责、避免流程拖延north star RFC 的撰写发生在 9 月从 9 月 1 日开始10 月 1 日前结束即 RFC 必须在 9 月的最后一周前进入 FCPfinal comment period。选 9 月的两个原因它是日历季度的最后一个月使新年工作能从日历 Q4 伊始展开而选 Q4 是因为它是传统的会议季有机会公开谈论前一年的进展与下一年的抱负。反之从 Q1 开始会遇到假期季的麻烦。季度规划周期紧随 9 月规划月之后每个日历季度开始时进行恰好一周的季度规划回顾报告在大约 8 月的一个月内开发撰写调查survey与其他外联、数据收集活动应配合整体日历进行安排。权衡与备选方案Drawbacks代价RFC 坦率列出了三方面代价年度 north star RFC 可能成为一场不愉快的 bikeshedding——它同时抬高了讨论 stakes、又偏离了具体提案不过问题导向应有助于缓和讨论而且明确表达价值观与优先级本身就是至关重要的提案在提升团队效能的同时给每个人增加了额外工作希望收益能超过成本年末回顾报告需要大量投入由谁、以何种质量去完成它并不明确这可能是整个提案中最需要后续跟进的环节。Alternatives备选方案RFC 也评估了替代路线纯数据派生不再给团队增加流程结构仅从团队当前正在产生的数据中推导路线图以软件产品替代回顾报告作为 rallying point例如推出比 rustccargo 更大的Rust 平台The Rust Platform产品概念长期支持LTS版本作为另一个 rallying point。未决问题RFC 记录了当时悬而未决的若干问题其中许多在后续实践中得到了回答一年周期是否足够长还是太长如果年度中途出现重大问题怎么办年度报告能否真正起到建立期待、激励和制造 PR-bomb 的作用固定的大周期时间是否真的合适现在发布周期太可预测以至于几乎无聊不预先知晓周期终点是否更有张力如何核算不在这套规划流程内的工作如何应对超出标准库与编译器范围的问题如何激励 rust-lang crates 与其他库的改进它们是否属于规划流程或回顾报告的范围problem statement措辞不够鼓舞人心goalretrospective也可以更有色彩能否把年度 RFC 直接称作north star RFC概念是否过多如何跟踪不属于R-problem-statement与R-goal的工作例如任意特性在 RFC 管线中的状态如何呈现路线图——这是本 RFC 的主要目标之一而当时提出的方案阅读R-problem-statementissues仍是最小实现。落地与演进从 2017 到 2026 的实践验证RFC 1728 不是一纸空文——本仓库完整保存了它落地后的全部历届路线图与后继流程可以直接对照阅读20171774-roadmap-2017 是依据 RFC 1728 产出的第一份年度路线图聚焦提升 Rust 的生产力涵盖学习曲线、编辑-编译-调试循环、基础 IDE 体验、高质量 crate 访问、高规模服务器支持等 8 项目标并探索语言互操作与资源受限环境两个方向20182314-roadmap-2018 提出发布 Rust 2018 edition建设中级 Rustacean 资源连接并赋能全球社区壮大 Rust 团队与新领袖四项年度目标并聚焦网络服务、WebAssembly、CLI 应用、嵌入式设备四大目标领域20192657-roadmap-2019 与20202857-roadmap-2020 分别围绕编译器与语言团队的 working group、以及治理带宽与设计讨论效率展开20213037-roadmap-2021 在 Prior art 一节专门回顾了这段历史RFC 1728 于 2016 年建立了路线图流程此后共有 4 份年度路线图全部包含一定量的治理工作2017 提供各层级指导、2018 壮大领导力与团队、2019 编译器与语言团队工作小组、2020 提升治理与设计讨论带宽并指出 2017/2019/2020 的共同挑战是缺乏明确、可达成目标而 2018 在设定明确目标方面做得更好但被 edition 工作挤占了资源。2021 之后路线图流程一度停摆3614-project-goals2024在 Prior art 中明确把 RFC 1728 作为前身并总结了三个教训路线图流程没有为目标指派 owner、没有有效跟踪机制、也没有为撰写路线图这项工作指派 owner。作为后继Project Goals 流程确立了目标是契约owner 承诺干活项目承诺支持问题优先于方案没有 owner 就不会有结果等设计公理并采用半年一轮的 goal slate 机制。此后本仓库中的 3672-Project-Goals-2024h226 个目标含发布 Rust 2024 editionAsync 与 sync 体验对齐解决 Linux 内核在 stable Rust 上构建的最大阻塞三大旗舰目标、3764-Project-Goals-2025h139 个目标以及 3935-Project-Goals-202666 个目标、改为年度周期均沿着这条演化路径展开。从仓库证据可以清楚看到RFC 1728 确立的年度规划周期 问题导向 目标跟踪 年终总结骨架被完整继承了下来只是把年度路线图 RFC R-problem-statement/R-goal标签的具体形态演进成了目标 slate 明确 owner/champion 定期进度更新的 Project Goals 流程——这正是该 RFC 在未决问题中预留的演化空间。参考在仓库中继续深入RFC 1728 原文——本文主体来源2017 路线图、2018 路线图、2019 路线图、2020 路线图、2021 路线图——历届年度路线图实践RFC 3614 Project Goals——路线图流程的后继实验含对 RFC 1728 的教训总结2024H2 目标清单、2025H1 目标清单、2026 目标清单——新流程下的历轮目标 slateREADME.md——Rust RFC 流程的总体说明RFC 1728 正是该流程下substantial change类提案的产物。一句话总结RFC 1728 用北极星隐喻回答了一个组织难题——一个由大量独立贡献者组成的大型开源项目如何既不丢失快速发布节奏又能每年围绕少数重大问题对齐愿景、跟踪进展、并向世界交付一个值得庆祝的故事。赞分享文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载相关推荐M/o/Vfuscator编译器路线图2030年愿景与技术目标M/o/Vfuscator编译器路线图2030年愿景与技术目标 M/o/Vfuscator作为全球首个单指令集C编译器自诞生以来就以仅用MOV指令实现图灵编译器happy-llm项目路线图更新2025年技术愿景happy llm项目路线图更新2025年技术愿景 引言大语言模型技术的拐点与机遇 你是否还在为大语言模型学习资源碎片化而困扰是否渴望一套既能掌握核心原理教程人工智能大模型深度学习NLP微调RAGAI Agentvolkswagen项目路线图详解短期目标与长期愿景volkswagen项目路线图详解短期目标与长期愿景 你是否曾遇到过本地测试通过但CI环境频繁失败的情况是否希望有一种工具能智能适配不同测试环境减少重复调测试上一篇Task 项目贡献指南从环境搭建、代码规范到文档双通道与 PR 提交流程下一篇PixelCNN核心架构深度解析门控残差网络与多GPU训练技术创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考