最近参与一个从零开始的开源项目，开完几次会议后正式分组准备进入第一阶段的功能实现，由于之前对 RFC 流程很有兴趣，就在 Discord 群里推广了下 RFC 流程。
TL;DR: 在没有实际产品前的开发阶段不适合使用 RFC，比较适合在有产品的开源项目里使用，以及大家有共识的工作流程才是好的工作流程。
什么是 RFC#
RFC (Request for Comments) 又称意见请求、意见征求，很多开源项目都能看到有自己的 RFC 工作流程
Rust
Bytecodealliance
Reactjs
VueJS
Ethereum
在开源项目里执行RFC 驱动开发的好处是任何改动可以透明的被讨论与取得共识，最后在根据定义好的 RFC 文件去实现改动。
自己也是第一次实现 RFC 流程，参考了几篇流程文章后，在 Discord 中与大家分享 (推坑 ，团队都对 RFC 流程很有兴趣但不知道该怎么执行，与有在执行 RFC 的朋友讨论跟其他公司的流程分享，最后起草了一份模板让大家来讨论。
RFC 驱动开发
Gatsby RFC 流程
起草的讨论#
为什么使用 RFC#
“RFC”（请求评论）流程旨在为产品（例如新功能）的变更提供一致和受控的路径，以便所有成员对项目的方向充满信心。
许多变更，包括错误修复和文档改进，可以通过正常的 GitHub 拉取请求工作流程来实施和审查。
然而，一些变更是 “实质性的”，我们要求这些变更经过一定的设计过程，并在产品社区中达成共识。
RFC 模板#
---
name: RFC
about: Suggest an idea for this project
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFC: [您的主题标题]
## 摘要
对所提议的功能或变更的简短、简洁的描述。这应该用于提供对提案的高层次理解。
## 动机
解释背景以及您为什么提出这个提案。需要解决的问题是什么？支持哪些用例？预期的结果是什么？
## 提案草图 / 详细设计
对于早期阶段的RFC，提供至少一个草图，以帮助将讨论集中在一个具体的起点上。
对于更详细的RFC，此部分应包含足够的信息，以便其他人理解和评估提案。它应涵盖关键点和设计考虑，包括对架构的讨论、设计细节的解释以及您选择背后的理由。
### 组件图
如果可能，请提供组件图。
### 时序图
如果可能，请提供时序图。
### 类图
如果它为提案增加价值和理解，请提供类图。
### OpenAPI规范
如果提案涉及API，请包含OpenAPI规范。
## 理由和替代方案
讨论选择提议设计的原因以及它所涉及的权衡。此外，描述已考虑的替代方案以及为何被放弃。
## 未解决的问题
讨论设计中仍未解决或需要进一步讨论的方面。可以分为两个部分，您希望在最终确定RFC之前回答的问题，以及在实施阶段将解决的问题。
## 缺点
该提案的潜在缺点是什么？对用户或现有系统有什么影响？
## 采用策略
如果提案被接受，请描述在您当前系统中采用的路径。集成策略是什么？
## 行动计划
列出RFC获得批准后需要完成的关键行动。如果可能，还包括讨论、审查和批准的日期。
- [ ] 设计讨论在YYYY-MM-DD
- [ ] RFC审查在YYYY-MM-DD
- [ ] RFC批准在YYYY-MM-DD
RFC 草稿模板#
---
name: RFC
about: Suggest an idea for this project
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFC标题
## 摘要
提供对变更的简短单段解释。
## 动机
描述提出此RFC的动机。当前状态是什么，为什么这个变更是有益的？支持哪些用例？预期的结果是什么？
## 提案草图
在这个阶段，提案不需要完全形成。一个草图足以集中讨论。高层次地详细说明提议的解决方案。如果引入了任何新概念或术语，请在此定义它们。
## 未解决的问题
设计的哪些部分仍然不清楚或需要解决？您希望通过与社区的讨论解决哪些问题，以便将此RFC推进到完整提案？
## 权衡
该提案的潜在权衡或影响是什么？如果有，它如何影响系统的其他领域？
## 未解决的问题
提案的哪些部分是待定的（待决定）？
讨论 RFC 流程#
-
讨论到 RFC：在仓库的讨论部分开始一个开放的讨论线程。在达成共识后，线程的作者起草 RFC。一旦 RFC 准备好，开发可以开始，最终以拉取请求结束。
-
草拟 RFC 到拉取请求：提议者通过创建草拟 RFC 并将其提交为草拟拉取请求来启动该过程。在讨论和完善后，拉取请求将正式审查，然后合并或关闭。
-
综合方法：在讨论部分开始初步讨论。一旦想法变得相对清晰和具体，转向起草 RFC 并将其提交为拉取请求，以便进行深入讨论和正式审查。这结合了讨论的开放性和 RFC 及拉取请求流程的结构化格式。
结论#
刚前面有提到，我参与的是从零开始设计讨论的开源项目，我们一开始的开会模式是使用 FigmaJam 做产品构思与讨论，而后面则是使用 google doc 记录了需要开发的功能，由于产品属于准备进入实现时期，大家讨论的点是在 spec 还未正式定案加上已有 google doc 版本的 spec 和 UIUX 对于 github 的操作流程不一定熟悉等的因素，我们做了一次投票，最终大家决定先以 google doc + FigmaJam 为主要开发文件，主要是开发初期要做好 RFC 文件对于大家都有难度，也会使产品的开发周期变得更长；最终大家有共识的工作流程才是最适合的工作流程。
如果觉得我的文章不错，欢迎买杯咖啡给我#
