该文档处于设想阶段，并未落地实践

参考

简介

RFC 全称 （Request for Comments），征求意见。

RFC 概念最早在 互联网 标准指定领域出现。在互联网技术标准领域，RFC 是技术标准文档的代名词，业界公认的主流的互联网技术，比如 TCP/IP 都编入了 IETF 的 RFC 文档中。换句话说，想成为互联网技术方面的标准或者基础设施，都需要进入 IETF 的 RFC 文档

在开源技术领域，古老的开源项目，比如 Linux，采用的是 邮件组的 方式来进行讨论及项目管理。

较新的开源项目，会考虑使用 Github + RFC + IM/论坛 机制来实现 Feature 管理。比如 Rust、React。

关于 Github 和 mail list 参见：博客

RFC 内容

参考：Rust RFC 项目管理调研 / 模板

开源项目的 RFC 使用姿势

开源项目的特点

  • 任何人都可以贡献代码
  • 贡献者间不熟悉，来自全球各地

开源项目贡献者角色分析

  • 意愿贡献者，想为开源项目贡献代码，但是还没有贡献（多数）
  • 普通贡献者，偶尔为开源项目贡献代码
  • 项目组核心成员，经常为项目贡献代码，同时负责开源项目管理，参与技术讨论，决策

开源项目管理的诉求

  • 新人能更容易的参与到迭代中
  • 核心成员对项目的迭代方向、代码质量有控制力

开源项目 RFC 的基本流程

物料准备

  • rfc 仓库，用来维护所有的 rfc 文档
  • rfc 仓库 PR 讨论区，作为 rfc 设计评审的讨论地点
  • 项目代码库
  • 项目代码库代码库的 Issue 讨论区，作为该 rfc 实现过程的讨论地点

角色（一人可能身兼数职）

  • 核心项目组成员
  • rfc 作者
  • rfc 实现者

RFC 创建、讨论、评审流程（工作在 rfc 仓库）

  • 确认如下问题
    • 查看所有历史 RFC，确认待创建的 RFC 不存在或者没有被拒绝
    • 该 Feature 不是 Bugfix、重构类的需求
  • Fork 代码库，根据模板编写 RFC
  • 提交 PR
  • 初步评审，项目组核心成员对该 RFC 质量，是否有重复等问题，决定是否进入下一阶段
  • 讨论阶段，相关利益相关方在此 PR 处进行讨论，作者根据讨论进行修改并 commit。讨论参与者如下
    • RFC 作者
    • 相关项目组核心成员
    • 所有感兴趣的其他人员
  • 最终动议阶段，RFC 作者 和 相关项目组核心成员认为可以进入最终动议阶段，则可以发起最终动议，公示一段时间后，没有问题，则激活 RFC。同时 该 RFC 的 PR 将合入 RFC 仓库

RFC 开发阶段（工作在 项目代码库）

  • 在项目代码库创建一个 Issue 用来追踪 RFC 的实现情况
  • 实现者（当然欢迎 RFC 作者作为实现者）认领该任务，进入开发阶段

商业项目管理 结合 RFC 机制

商业项目的特点

与开源项目不同，商业项目

  • 研发成员相互之间在同一地点办公，彼此熟悉
  • 能参与讨论的成员相对较少，核心开发一般较少
  • 存在 PM 、测试 角色，分工更细，需求一般偏业务
  • 迭代速度要求尽量快，代码质量要求相对迭代速度优先级低一些

流程设计

仅设想阶段

使用 RFC 管理 需求

  • 参考 Rust RFC 项目管理调研 / 模板 给出 RFC 模板，该模板需要按照业务类型需求重新设计，主要包含 PRD、 技术方案、测试验收方案的内容
  • 一个 RFC 一般需要三种角色
    • PM
    • 技术（两人）
    • 测试
  • RFC 文档 可以使用公司内部的 在线 Doc 平台 （需附上 IM 群） 或者 Gitlab （推荐） 中编写，使用标签或者在文章中添加状态或者使用需求管理软件管理状态，来管理 RFC 生命周期
  • RFC 评审
    • 评审的形式不一定是会议，可以是评论、论坛、群聊的方式
    • 一般有两次：产品方案评审、技术方案评审
    • 更新 RFC 的状态
  • 开发阶段
    • 更新 RFC 的状态，并添加一个 Issue 的链接
    • 使用 Issue 管理 RFC 的实现，在描述上关联上 RFC 的链接
    • Gitlab 的多个 MR 上关联上 Issue，一个技术提交必须要另外的一个技术的 Review
  • 验收阶段，测试进行测试，验收阶段结束后，关闭 Issue，更新 RFC 状态，并最后校验文档和实现是否脱节

优缺点

优点

  • 更标准化的管理方案文档和代码实现以及两者相互索引，提高项目质量
  • 因为存在众多 RFC 文档，且 RFC 文档的讨论和 MR 或者 PR 都有管理，所以新人更容易快速进入状态，了解历史进度
  • 扩大所有人对项目的 context 的了解，不至于出现人员点单，降低人员变更带来的风险
  • 方案指导开发，给开发人员一种普遍的方案设计思路，提高开发人员的核心素质，培养开发人员工程师思维（做 Engineer、Developer 摆脱 coder）

缺点

  • 部分程序员无法将设计和开发彻底分离，设计后置到开发阶段，也就是说该这种程序员在设计阶段的想法无法落实在开发上。这将导致
    • 存在阵痛期，认为写 RFC 是浪费时间，心理上会有抵触情绪
    • 产出的 RFC 和代码不符，导致 RFC 文档反而误导其他成员
    • 需要要求开发者有 Owner 精神
  • 一定程度降低迭代速度