2020 年 5 月，我提议了一个更加简单的流程：

该提议的目的是引入 「Review」 状态，并移除所有协调硬分叉的尝试。这样可以统一 「核心」 EIP 和 「非核心」 EIP 的流程。但是，为了方便起见，我略去了协调硬分叉的部分。

关于这点，我们已经进行过讨论。但是就像很多在走 EIP 流程的提案一样，这个提议并未得到推进。

引起争论的还有是否应该将 「Withdrawn」 和 「Abandoned」 这两个状态合并的问题。在最近的议题中，这一点已经有了明确的解释。

在电话会议上，还有人建议用 「Living （生效）」 一词来代替 「Active （激活）」 。前者或许不是最佳选择，但是听起来优于后者。

硬分叉

我赞成将硬分叉管理和规范管理这两个过程分开。现在看来，似乎有很多人都这么认为。这样可以让流程变得更加简单流畅。

根据全体核心开发者会议上的新消息，现在似乎有一个 ETH 1.0 规范库专门追踪和管理提案，并在所谓的 「YOLO」 临时测试网上进行测试。

我认为，即使将最后残余的硬分叉流程从 EIP 库中移除，EIP-233 最初的构想依然是合理的：将已有的硬分叉记录到元文档中（跟描述规范变更的 EIP 放在一起）

然而，人们在 EIP-233 的最初构想上迈开了一步，规则变成了尽快创建元文档以明确硬分叉的名称，因为不同的客户端使用不同的名称。但是在命名机制得到一致认可后，这个问题就不再是问题了。

最后，EIP-233 的构想再次延伸，延伸出了在计划和协调过程中追踪硬分叉的流程。幸运的是，以后这将由 ETH 1.0 规范来处理。

硬分叉发生后，所有数据都记录在 「hard fork metas」 中。事实证明，hard ford metas 是一种非常有用的资源。

我建议的流程

要想站在巨人的肩膀上，我们所能找到的最好资源是 RFC 流程和 W3C 流程。尽管这两个流程所涉及的规范通常比 EIP 大得多，但是我认为我们可以向它们取经。

这里，我从 W3C 流程借用了一些我个人比较喜欢的术语。不过，上图还给出了其它选择，都是现有术语或提议术语。我个人更倾向于 「Candidate （候选）」 这个术语。

Idea （构想）

任何提案在提交以前，都应该有一个深思熟虑的阶段，再提交创建草案的 pull request （拉取请求）。我们可以在 Ethereum Magicians、ethresear.ch，以及 Gitter 或 Discord 上的频道讨论和评议构想。 (责任编辑：admin)