介绍 electron/rfcs
Electron 的 API 工作组 正在采用开放的征求意见稿 (RFC) 流程，以帮助引导 Electron 核心的更大变更。
为何采用 RFC？
简而言之，我们希望简化将重大更改引入 Electron 核心的过程。
目前，新的代码更改主要通过 GitHub 上的 issue 和 pull request 进行讨论。对于 Electron 的大多数更改来说，这是一个很好的系统。许多错误修复、文档更改，甚至新功能都足够简单，可以通过标准的 GitHub 流程进行异步审查和合并。
对于更重要的更改——例如，大型 API 表面或会影响大多数 Electron 应用的重大更改——在编写大部分代码之前，在构思阶段进行审查是有意义的。
此过程旨在对公众开放，这也将使更广泛的开源社区更容易在潜在更改进入 Electron 之前提供反馈。
它是如何运作的？
整个 RFC 流程都在 GitHub 上的 electron/rfcs 仓库中。步骤在仓库的 README 中详细描述。
简而言之，一旦向 electron/rfcs 仓库提交 PR，RFC 就被提议。提议的 RFC 变为
- 当 PR 合并到仓库的
main分支时，变为活动状态，这意味着 Electron 维护者同意在electron/electron中进行实现，或者 - 如果 PR 最终被拒绝，则变为拒绝状态。
为了使 RFC 变为活动状态，PR 必须获得至少 2 名 API 工作组成员的批准。在合并之前，RFC 应该同步展示，并由至少三分之二的 WG 成员的法定人数一致接受。如果达成共识，将触发为期一个月的最终评论期，之后 PR 将被合并。
如果实现已合并到 electron/electron 中，则活动 RFC 将完成。
谁可以参与？
Electron 社区中的任何人都可以提交 RFC 或在 electron/rfcs 仓库中留下反馈！
我们希望使这个过程成为双向对话，并鼓励社区参与，以从未来可能使用这些 API 的 Electron 应用中获得各种意见。如果您有兴趣对当前提议的 RFC 留下反馈，Electron 维护者已经创建了一些
鸣谢
Electron 的 RFC 流程是仿照许多已建立的开源 RFC 流程建模的。许多想法和文案主要部分的灵感来自