Carbon 项目年度路线图流程Roadmap Process深度解读从 OKR 制定到季度调整的治理机制【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang本篇技术指南聚焦 Carbon Language 仓库中的 docs/project/roadmap_process.md系统拆解 Carbon 项目年度路线图的制定、审查、约束力与调整机制。通过阅读本文你将理解路线图为何以标准提案流程而非内部决策的方式产生、OKR目标与关键结果如何锚定在 goals 与 success criteria 之上、年度时间线如何运转以及路线图如何在不严格绑定与用于推迟提案之间取得平衡。文中所有结论均以仓库内实际文档与源码为据可直接对照深入阅读。路线图在 Carbon 治理体系中的定位Carbon 项目将自身定位为探索 C 可能未来的实验性语言其长期演进依赖一套明确的治理与演化机制。在 docs/project/evolution.md 中Carbon leads项目领导的职责被明确为审查提案、设定 Carbon 的路线图roadmap_process.md并管理演化且采用带两人法定人数的阻塞共识blocking consensus进行决策。路线图roadmap与里程碑milestone是两套互补的时间尺度年度路线图如 docs/project/roadmap.md 所示提供当年具体且即时的优先级集合长期里程碑如 docs/project/milestones.md 所述是横跨一年多、具有功能动机的长期目标并通过 0.1、0.2、1.0 等版本号方便引用。roadmap_process.md 规定的正是前者——年度路线图如何产生、如何被使用、如何被调整的完整流程。为什么需要年度路线图对齐与聚焦原文档开篇即点明了路线图的核心动机Carbon 拥有年度路线图用于对齐并聚焦各团队与社区的工作。团队将需要推迟那些可能好且有道理、但与项目当前焦点和计划不一致的 Carbon 工作。这段话包含了两个关键信息对齐align路线图让分布在多个子团队subteams与整个社区中的工作朝同一方向前进聚焦focus它给出一个明确的判断基准——即使是好的提议只要与当前焦点不符也应当被推迟而不是无差别接受。这一点与 docs/project/goals.md 中我们预期会不可避免地做出让部分社区成员受益更多的选择并会为这些决策提供理由但实现 Carbon 的目标将是指导规则的表述一脉相承路线图就是把目标落到年度执行的中间层工具。路线图的产生核心团队起草 标准提案流程原文档规定核心团队core team将每年起草提议的路线图走标准的提案审查流程。这里需要特别注意标准的提案审查流程这一表述。Carbon 的所有实质性变更——包括语言、项目、基础设施——都必须通过演化提案evolution proposal进行其完整机制记录在 docs/project/evolution.md提案以 GitHub Pull Request 形式呈现在proposals/目录新增文档遵循 proposals/scripts/template.md 模板提案 PR 从 draft 模式开始就绪后点击 Ready for review会路由给一位 Carbon lead 审查、以 RFC 形式发给整个社区并打上 proposal rfc 标签跟踪提案文档命名遵循proposals/p######-slug.md约定其中######是 PR 号补足 6 位slug是标题的 URL 友好版本获批的提案会被合并被推迟或拒绝的提案由审查 lead 说明原因并关闭 PR。也就是说年度路线图本身不是核心团队的单方面指令而是一份提交给社区审查、可以被打回或修改的正式提案。仓库中历年路线图正以提案形式留存可直接对照验证这一机制proposals/p001025-roadmap-for-2022.mdproposals/p002551-roadmap-for-2023-and-retrospective-for-2022.mdproposals/p003564-roadmap-for-2024-and-a-retrospective-for-2023.mdproposals/p004880-safety-milestones-and-a-2025-roadmap.md尤其值得留意的是多份路线图提案带有Retrospective回顾后缀说明路线图流程天然包含对过去一年执行情况的复盘再据此调整来年方向。提案作者侧的实操路径对于想要撰写路线图或其他任何提案的贡献者仓库提供了现成的脚手架模板文件proposals/scripts/template.md包含 Abstract、Problem、Background、Proposal、Details、Rationale、Alternatives considered 等标准章节脚手架脚本proposals/scripts/new_proposal.py模板提示运行./new_proposal.py TITLE即可完成新提案初始化配套测试proposals/scripts/new_proposal_test.py用于验证脚本行为。OKR 的三个来源目标、成功标准与战术特性原文档对路线图中的目标与关键结果Objectives and Key ResultsOKR给出了明确的锚定关系目标与关键结果将基于 goals、success criteria 和战术特性tactical features。这意味着 OKR 不是凭空拍脑袋而是三层输入的交汇Goals项目目标docs/project/goals.md 列出了七大语言目标并按优先级排序——性能关键软件、软件与语言演化、易于阅读/理解/编写的代码、实用的安全与测试机制、快速可扩展的开发、现代 OS 平台与硬件环境、与现有 C 代码的互操作及迁移。路线图的优先级排序必须服从这一既定顺序。Success criteria成功标准docs/project/principles/success_criteria.md 将目标细化为具体、可度量的关键结果并明确声明成功标准将作为 Carbon 路线图流程的一部分被考虑未能达成将被视为重大问题。例如该文档给出了一个可量化的迁移工具标准给定遵循最佳实践的大型代码库目标是不超过 2% 的文件需要人工交互。这类量化指标正是 OKR 中关键结果的天然来源。Tactical features战术特性指当年需要推进的具体语言/工具链功能点例如 docs/project/roadmap.md 中 2025 年列出的C 互操作演示与内存安全具体设计两大目标下的各项具体工作。成功标准的双向约束作用值得展开的是 success criteria 对路线图的约束方式。原文档 docs/project/principles/success_criteria.md 规定成功标准是我们期望用来衡量项目目标达成情况的特定、可度量关键结果它被纳入路线图流程考量未达成将被视为重大事件任何会削弱成功标准的提案都将受到额外审查。这形成了一条完整的治理链条goals 定义方向 → success criteria 定义可度量的刻度 → 年度路线图把这些刻度落实为当年的 OKR → 提案若与 OKR 冲突则被推迟。路线图流程文档正是这条链条的装配说明。年度时间线决策审查与季度评估原文档对路线图的时间节奏给出了明确安排预期核心团队将在年初第一件事就提供草案决策并进入决策审查decision review最终形成当年项目总体方向的已接受计划plan of record。这条规定可拆解为三个要点年初启动路线图草案必须在年初第一件事就绪尽早进入决策流程避免团队在等待方向时无所适从决策审查decision review草案决策需要经过正式审查环节这与 docs/project/evolution.md 中提案获批后 lead 负责解决所有阻塞问题的决策机制衔接产出物是 plan of record最终批准的路线图成为项目当年总体方向的记录在案的计划后续工作以此为准绳。此外原文档还要求在项目初始阶段核心团队应按季度批判性地评估方向与任何新信息并根据需要调整路线图以保持聚焦于最重要的事项。这意味着年度路线图并非年初定完就冻结而是有明确的季度复盘机制。任何新信息例如 C 互操作遇到的技术障碍、社区反馈、外部环境变化都可能触发方向调整——但调整本身也必须遵循同一套演化流程见下文路线图如何变更一节。子团队Subteams的可选路线图原文档特别指出子团队可以按需为各自负责的 Carbon 领域采取类似的实践。在 docs/project/evolution.md 中子团队被定义为为特定领域提供领导力的团队组织方式大致与 Carbon leads 相似但范围更窄且子团队的决策可能被升级到 Carbon leads。因此子团队路线图是可选而非强制的机制当某个领域如标准库、工具链、格式化工具的工作量足够大、需要自身聚焦时子团队可参照核心团队的年度流程为自己的领域起草并批准路线图但最终仍受项目级路线图的约束与协调。当前仓库中 docs/project/teams 目录维护了各团队的相关说明。路线图的约束力边界不严格绑定但可推迟提案原文档对路线图的效力给出了精确的边界描述这是整个流程中最容易被误解的部分该路线图并非严格绑定也不需要涵盖将要发生的一切。然而它可以且应当被团队用来按需推迟一些提案以聚焦于与当前路线图一致的提案。这句话同时划定了非约束面和约束面非约束面路线图不是穷尽的工作清单也不构成对未列出工作的禁令——未列入路线图的工作只要合理仍可能推进路线图也不强制团队必须只做列出的工作约束面当提案与当前路线图冲突时团队可以且应当使用路线图作为推迟该提案的理由。这是路线图最重要的操作价值它为说 不提供了制度化依据。换言之路线图的本质是优先级工具而非工作清单。这与 docs/project/evolution.md 中任何实质性变更都应通过演化提案的规则协同提案负责提出方向路线图负责裁定这个方向今年该不该做。路线图如何变更以新提案驱动调整原文档最后一条核心规定路线图与其他任何文档一样可以随时变更只需提交一份新的提案。核心团队应在项目初始阶段按季度批判性评估方向与任何新信息并根据需要调整路线图。这条规定有几个要点变更的正式通道是新提案路线图变更不是核心团队的口头调整而是与年度路线图同等规格的提案流程——社区可见、可讨论、有审查记录。这与 docs/project/evolution.md 中创建清晰的、关于项目与语言为何朝特定方向演化的理由日志的目标一致变更的触发是新信息季度评估的目的是发现方向与新信息之间的偏差而非机械地完成任务清单变更的初衷是保持聚焦任何调整都以聚焦于最重要的事项为最终判据避免项目在实验阶段被枝节议题稀释。结合 docs/project/goals.md 中支持语言本身持续数十年的维护与演化以及live-at-head紧跟主干模型这一机制的深层逻辑是路线图流程必须足够轻量才能与项目自身的高频演化节奏匹配。路线图与里程碑、版本化的衔接虽然 roadmap_process.md 本身不展开里程碑细节但仓库中路线图的下游衔接非常清晰理解这一点有助于完整把握路线图流程的产出物去向年度路线图 → 里程碑docs/project/milestones.md 明确说明年度路线图提供当年具体且即时的优先级但希望接续年份指向一致的方向与有意义的最终目标即里程碑通常横跨多年、具有功能动机。仓库中 2025 年路线图docs/project/roadmap.md与里程碑的联动是一个很好的实例2025 年两大目标之一是为 Carbon 构建具体而明确的内存安全设计该路线图指出因为我们正在向 0.1 里程碑添加内存安全设计也预计将 0.1 至少推迟一年——2026 年底成为 0.1 现实的最早可能时间之后的时间框架2027–2028 完成 0.2、结束实验2028 之后发布 1.0 并完成治理移交都在 docs/project/roadmap.md 的 Beyond 2025 一节中作了高层展望。里程碑 → 版本号docs/project/versioning.md 将里程碑与语义化版本衔接起来Carbon 在 0.x 阶段主要使用 minor 版本增量来跟踪通向 1.0 里程碑的进度因此定义了 0.1 与 0.2 里程碑。版本号规则本身也遵循 SemVer 2.0.0MAJOR.MINOR.PATCH三段式向后不兼容的变更到达 1.0 里程碑后递增 MAJOR在此之前递增 MINOR纯 bug 修复递增 PATCH预发布后缀-rc.N发布候选、-0.nightly.YYYY.MM.DD每夜构建、-0.dev开发构建。路线图内容 → 提案清单以 docs/project/roadmap.md 为例2025 年 OKR 包括在 Carbon 中访问大多数非模板 C API排除协程、以及需要在 C 中使用 Carbon 类型的场景如以 Carbon 类型作为模板参数在 C 中访问非泛型 Carbon API明确排除泛型以收窄范围并注明这是 2025 的伸展目标更新详细的安全策略包括预期的取舍与优先级排序设计编译期时间性temporal与可变性mutation内存安全文档明确表示最高层面的方向跟随 Rust即用类型系统在编译期保证安全避免 GC 或引用计数的运行时开销同时强调安全门槛需要与 Swift、Kotlin、Go、Rust 等现代语言看齐在 2–3 场会议上进行 Carbon 主题演讲扩展受众明确希望覆盖亚太地区会议以及 LLVM/C 之外的更广泛开源会议。这些 OKR 与 docs/project/principles/safety_strategy.md 中debug / performance / hardened 三种构建模式的安全策略、以及 docs/project/principles/success_criteria.md 的量化迁移指标相互呼应构成了策略→路线图→度量的闭环。给贡献者的实操建议结合 docs/project/evolution.md 与 proposals/scripts/template.md如果你作为社区贡献者想推动一项工作进入路线图或与之对齐可遵循以下路径先读路线图docs/project/roadmap.md 是当年的 plan of record。确认你的工作是否与当年 OKR 一致如果不一致明确它可能被推迟的预期理解推迟不是拒绝路线图不严格绑定被推迟的提案可以在后续年度重新提交路线图变更本身也可由新提案驱动用标准提案流程提出方向使用new_proposal.py脚手架proposals/scripts/new_proposal.py按模板创建提案文档作为 PR 提交并申请 review让 lead 与社区参与决策用成功标准量化目标撰写提案时尽量参照 docs/project/principles/success_criteria.md 的度量风格如少于 2% 文件需人工交互使目标可验证、可被路线图纳入关注季度调整窗口路线图按季度评估调整如果你的提案有强时效性可在评估周期内主动向核心团队提供信息。总结roadmap_process.md 用不足一页的篇幅定义了一套完整的年度方向治理机制其要点可归纳为维度机制仓库依据制定主体核心团队起草走标准提案审查流程docs/project/evolution.mdOKR 输入goals、success criteria、战术特性docs/project/goals.md、docs/project/principles/success_criteria.md年度节奏年初进入决策审查形成 plan of recorddocs/project/roadmap.md复盘节奏初始阶段按季度批判性评估并调整原文档子团队可参照类似实践为各自领域制定路线图docs/project/evolution.md约束力非严格绑定用于按需推迟不聚焦的提案原文档变更方式与其他文档相同由新提案驱动docs/project/evolution.md下游衔接年度路线图→多年里程碑→SemVer 版本号docs/project/milestones.md、docs/project/versioning.md这套机制的精髓在于它既承认方向需要聚焦又拒绝让聚焦变成僵化。路线图通过标准提案流程产生、可被新提案随时修改、按季度被批判性审视同时保持推迟不聚焦提案的实际效力——这种有约束力的聚焦与开放的演化之间的平衡正是 Carbon 在实验阶段维持社区凝聚力的治理基础。【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Carbon 项目年度路线图流程（Roadmap Process）深度解读：从 OKR 制定到季度调整的治理机制
Carbon 项目年度路线图流程Roadmap Process深度解读从 OKR 制定到季度调整的治理机制【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang本篇技术指南聚焦 Carbon Language 仓库中的 docs/project/roadmap_process.md系统拆解 Carbon 项目年度路线图的制定、审查、约束力与调整机制。通过阅读本文你将理解路线图为何以标准提案流程而非内部决策的方式产生、OKR目标与关键结果如何锚定在 goals 与 success criteria 之上、年度时间线如何运转以及路线图如何在不严格绑定与用于推迟提案之间取得平衡。文中所有结论均以仓库内实际文档与源码为据可直接对照深入阅读。路线图在 Carbon 治理体系中的定位Carbon 项目将自身定位为探索 C 可能未来的实验性语言其长期演进依赖一套明确的治理与演化机制。在 docs/project/evolution.md 中Carbon leads项目领导的职责被明确为审查提案、设定 Carbon 的路线图roadmap_process.md并管理演化且采用带两人法定人数的阻塞共识blocking consensus进行决策。路线图roadmap与里程碑milestone是两套互补的时间尺度年度路线图如 docs/project/roadmap.md 所示提供当年具体且即时的优先级集合长期里程碑如 docs/project/milestones.md 所述是横跨一年多、具有功能动机的长期目标并通过 0.1、0.2、1.0 等版本号方便引用。roadmap_process.md 规定的正是前者——年度路线图如何产生、如何被使用、如何被调整的完整流程。为什么需要年度路线图对齐与聚焦原文档开篇即点明了路线图的核心动机Carbon 拥有年度路线图用于对齐并聚焦各团队与社区的工作。团队将需要推迟那些可能好且有道理、但与项目当前焦点和计划不一致的 Carbon 工作。这段话包含了两个关键信息对齐align路线图让分布在多个子团队subteams与整个社区中的工作朝同一方向前进聚焦focus它给出一个明确的判断基准——即使是好的提议只要与当前焦点不符也应当被推迟而不是无差别接受。这一点与 docs/project/goals.md 中我们预期会不可避免地做出让部分社区成员受益更多的选择并会为这些决策提供理由但实现 Carbon 的目标将是指导规则的表述一脉相承路线图就是把目标落到年度执行的中间层工具。路线图的产生核心团队起草 标准提案流程原文档规定核心团队core team将每年起草提议的路线图走标准的提案审查流程。这里需要特别注意标准的提案审查流程这一表述。Carbon 的所有实质性变更——包括语言、项目、基础设施——都必须通过演化提案evolution proposal进行其完整机制记录在 docs/project/evolution.md提案以 GitHub Pull Request 形式呈现在proposals/目录新增文档遵循 proposals/scripts/template.md 模板提案 PR 从 draft 模式开始就绪后点击 Ready for review会路由给一位 Carbon lead 审查、以 RFC 形式发给整个社区并打上 proposal rfc 标签跟踪提案文档命名遵循proposals/p######-slug.md约定其中######是 PR 号补足 6 位slug是标题的 URL 友好版本获批的提案会被合并被推迟或拒绝的提案由审查 lead 说明原因并关闭 PR。也就是说年度路线图本身不是核心团队的单方面指令而是一份提交给社区审查、可以被打回或修改的正式提案。仓库中历年路线图正以提案形式留存可直接对照验证这一机制proposals/p001025-roadmap-for-2022.mdproposals/p002551-roadmap-for-2023-and-retrospective-for-2022.mdproposals/p003564-roadmap-for-2024-and-a-retrospective-for-2023.mdproposals/p004880-safety-milestones-and-a-2025-roadmap.md尤其值得留意的是多份路线图提案带有Retrospective回顾后缀说明路线图流程天然包含对过去一年执行情况的复盘再据此调整来年方向。提案作者侧的实操路径对于想要撰写路线图或其他任何提案的贡献者仓库提供了现成的脚手架模板文件proposals/scripts/template.md包含 Abstract、Problem、Background、Proposal、Details、Rationale、Alternatives considered 等标准章节脚手架脚本proposals/scripts/new_proposal.py模板提示运行./new_proposal.py TITLE即可完成新提案初始化配套测试proposals/scripts/new_proposal_test.py用于验证脚本行为。OKR 的三个来源目标、成功标准与战术特性原文档对路线图中的目标与关键结果Objectives and Key ResultsOKR给出了明确的锚定关系目标与关键结果将基于 goals、success criteria 和战术特性tactical features。这意味着 OKR 不是凭空拍脑袋而是三层输入的交汇Goals项目目标docs/project/goals.md 列出了七大语言目标并按优先级排序——性能关键软件、软件与语言演化、易于阅读/理解/编写的代码、实用的安全与测试机制、快速可扩展的开发、现代 OS 平台与硬件环境、与现有 C 代码的互操作及迁移。路线图的优先级排序必须服从这一既定顺序。Success criteria成功标准docs/project/principles/success_criteria.md 将目标细化为具体、可度量的关键结果并明确声明成功标准将作为 Carbon 路线图流程的一部分被考虑未能达成将被视为重大问题。例如该文档给出了一个可量化的迁移工具标准给定遵循最佳实践的大型代码库目标是不超过 2% 的文件需要人工交互。这类量化指标正是 OKR 中关键结果的天然来源。Tactical features战术特性指当年需要推进的具体语言/工具链功能点例如 docs/project/roadmap.md 中 2025 年列出的C 互操作演示与内存安全具体设计两大目标下的各项具体工作。成功标准的双向约束作用值得展开的是 success criteria 对路线图的约束方式。原文档 docs/project/principles/success_criteria.md 规定成功标准是我们期望用来衡量项目目标达成情况的特定、可度量关键结果它被纳入路线图流程考量未达成将被视为重大事件任何会削弱成功标准的提案都将受到额外审查。这形成了一条完整的治理链条goals 定义方向 → success criteria 定义可度量的刻度 → 年度路线图把这些刻度落实为当年的 OKR → 提案若与 OKR 冲突则被推迟。路线图流程文档正是这条链条的装配说明。年度时间线决策审查与季度评估原文档对路线图的时间节奏给出了明确安排预期核心团队将在年初第一件事就提供草案决策并进入决策审查decision review最终形成当年项目总体方向的已接受计划plan of record。这条规定可拆解为三个要点年初启动路线图草案必须在年初第一件事就绪尽早进入决策流程避免团队在等待方向时无所适从决策审查decision review草案决策需要经过正式审查环节这与 docs/project/evolution.md 中提案获批后 lead 负责解决所有阻塞问题的决策机制衔接产出物是 plan of record最终批准的路线图成为项目当年总体方向的记录在案的计划后续工作以此为准绳。此外原文档还要求在项目初始阶段核心团队应按季度批判性地评估方向与任何新信息并根据需要调整路线图以保持聚焦于最重要的事项。这意味着年度路线图并非年初定完就冻结而是有明确的季度复盘机制。任何新信息例如 C 互操作遇到的技术障碍、社区反馈、外部环境变化都可能触发方向调整——但调整本身也必须遵循同一套演化流程见下文路线图如何变更一节。子团队Subteams的可选路线图原文档特别指出子团队可以按需为各自负责的 Carbon 领域采取类似的实践。在 docs/project/evolution.md 中子团队被定义为为特定领域提供领导力的团队组织方式大致与 Carbon leads 相似但范围更窄且子团队的决策可能被升级到 Carbon leads。因此子团队路线图是可选而非强制的机制当某个领域如标准库、工具链、格式化工具的工作量足够大、需要自身聚焦时子团队可参照核心团队的年度流程为自己的领域起草并批准路线图但最终仍受项目级路线图的约束与协调。当前仓库中 docs/project/teams 目录维护了各团队的相关说明。路线图的约束力边界不严格绑定但可推迟提案原文档对路线图的效力给出了精确的边界描述这是整个流程中最容易被误解的部分该路线图并非严格绑定也不需要涵盖将要发生的一切。然而它可以且应当被团队用来按需推迟一些提案以聚焦于与当前路线图一致的提案。这句话同时划定了非约束面和约束面非约束面路线图不是穷尽的工作清单也不构成对未列出工作的禁令——未列入路线图的工作只要合理仍可能推进路线图也不强制团队必须只做列出的工作约束面当提案与当前路线图冲突时团队可以且应当使用路线图作为推迟该提案的理由。这是路线图最重要的操作价值它为说 不提供了制度化依据。换言之路线图的本质是优先级工具而非工作清单。这与 docs/project/evolution.md 中任何实质性变更都应通过演化提案的规则协同提案负责提出方向路线图负责裁定这个方向今年该不该做。路线图如何变更以新提案驱动调整原文档最后一条核心规定路线图与其他任何文档一样可以随时变更只需提交一份新的提案。核心团队应在项目初始阶段按季度批判性评估方向与任何新信息并根据需要调整路线图。这条规定有几个要点变更的正式通道是新提案路线图变更不是核心团队的口头调整而是与年度路线图同等规格的提案流程——社区可见、可讨论、有审查记录。这与 docs/project/evolution.md 中创建清晰的、关于项目与语言为何朝特定方向演化的理由日志的目标一致变更的触发是新信息季度评估的目的是发现方向与新信息之间的偏差而非机械地完成任务清单变更的初衷是保持聚焦任何调整都以聚焦于最重要的事项为最终判据避免项目在实验阶段被枝节议题稀释。结合 docs/project/goals.md 中支持语言本身持续数十年的维护与演化以及live-at-head紧跟主干模型这一机制的深层逻辑是路线图流程必须足够轻量才能与项目自身的高频演化节奏匹配。路线图与里程碑、版本化的衔接虽然 roadmap_process.md 本身不展开里程碑细节但仓库中路线图的下游衔接非常清晰理解这一点有助于完整把握路线图流程的产出物去向年度路线图 → 里程碑docs/project/milestones.md 明确说明年度路线图提供当年具体且即时的优先级但希望接续年份指向一致的方向与有意义的最终目标即里程碑通常横跨多年、具有功能动机。仓库中 2025 年路线图docs/project/roadmap.md与里程碑的联动是一个很好的实例2025 年两大目标之一是为 Carbon 构建具体而明确的内存安全设计该路线图指出因为我们正在向 0.1 里程碑添加内存安全设计也预计将 0.1 至少推迟一年——2026 年底成为 0.1 现实的最早可能时间之后的时间框架2027–2028 完成 0.2、结束实验2028 之后发布 1.0 并完成治理移交都在 docs/project/roadmap.md 的 Beyond 2025 一节中作了高层展望。里程碑 → 版本号docs/project/versioning.md 将里程碑与语义化版本衔接起来Carbon 在 0.x 阶段主要使用 minor 版本增量来跟踪通向 1.0 里程碑的进度因此定义了 0.1 与 0.2 里程碑。版本号规则本身也遵循 SemVer 2.0.0MAJOR.MINOR.PATCH三段式向后不兼容的变更到达 1.0 里程碑后递增 MAJOR在此之前递增 MINOR纯 bug 修复递增 PATCH预发布后缀-rc.N发布候选、-0.nightly.YYYY.MM.DD每夜构建、-0.dev开发构建。路线图内容 → 提案清单以 docs/project/roadmap.md 为例2025 年 OKR 包括在 Carbon 中访问大多数非模板 C API排除协程、以及需要在 C 中使用 Carbon 类型的场景如以 Carbon 类型作为模板参数在 C 中访问非泛型 Carbon API明确排除泛型以收窄范围并注明这是 2025 的伸展目标更新详细的安全策略包括预期的取舍与优先级排序设计编译期时间性temporal与可变性mutation内存安全文档明确表示最高层面的方向跟随 Rust即用类型系统在编译期保证安全避免 GC 或引用计数的运行时开销同时强调安全门槛需要与 Swift、Kotlin、Go、Rust 等现代语言看齐在 2–3 场会议上进行 Carbon 主题演讲扩展受众明确希望覆盖亚太地区会议以及 LLVM/C 之外的更广泛开源会议。这些 OKR 与 docs/project/principles/safety_strategy.md 中debug / performance / hardened 三种构建模式的安全策略、以及 docs/project/principles/success_criteria.md 的量化迁移指标相互呼应构成了策略→路线图→度量的闭环。给贡献者的实操建议结合 docs/project/evolution.md 与 proposals/scripts/template.md如果你作为社区贡献者想推动一项工作进入路线图或与之对齐可遵循以下路径先读路线图docs/project/roadmap.md 是当年的 plan of record。确认你的工作是否与当年 OKR 一致如果不一致明确它可能被推迟的预期理解推迟不是拒绝路线图不严格绑定被推迟的提案可以在后续年度重新提交路线图变更本身也可由新提案驱动用标准提案流程提出方向使用new_proposal.py脚手架proposals/scripts/new_proposal.py按模板创建提案文档作为 PR 提交并申请 review让 lead 与社区参与决策用成功标准量化目标撰写提案时尽量参照 docs/project/principles/success_criteria.md 的度量风格如少于 2% 文件需人工交互使目标可验证、可被路线图纳入关注季度调整窗口路线图按季度评估调整如果你的提案有强时效性可在评估周期内主动向核心团队提供信息。总结roadmap_process.md 用不足一页的篇幅定义了一套完整的年度方向治理机制其要点可归纳为维度机制仓库依据制定主体核心团队起草走标准提案审查流程docs/project/evolution.mdOKR 输入goals、success criteria、战术特性docs/project/goals.md、docs/project/principles/success_criteria.md年度节奏年初进入决策审查形成 plan of recorddocs/project/roadmap.md复盘节奏初始阶段按季度批判性评估并调整原文档子团队可参照类似实践为各自领域制定路线图docs/project/evolution.md约束力非严格绑定用于按需推迟不聚焦的提案原文档变更方式与其他文档相同由新提案驱动docs/project/evolution.md下游衔接年度路线图→多年里程碑→SemVer 版本号docs/project/milestones.md、docs/project/versioning.md这套机制的精髓在于它既承认方向需要聚焦又拒绝让聚焦变成僵化。路线图通过标准提案流程产生、可被新提案随时修改、按季度被批判性审视同时保持推迟不聚焦提案的实际效力——这种有约束力的聚焦与开放的演化之间的平衡正是 Carbon 在实验阶段维持社区凝聚力的治理基础。【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考