Draft （草案）假设某个构想引起了人们的兴趣，我们就应该基于 EIP 模版为其创建草案。只要这个草案符合基本的语法要求，我们就应该将其合并。 问题：关于编辑应有多大的审核提案的权限，人们的观点各不相同，目前还没有明确的答案。如果我们有一个良好的流程来移除不成功的 EIP，那么早一点合并草案无疑是正确的做法。 在这一阶段，预期会有一小群感兴趣的参与者对草案进行讨论。 「Draft」 状态没有时间限制，但是建议不要超过合理的时间范围（几个月）。 Candidate （候选）/Review （审核）一旦草案足够稳定，预期不会再进行重大修改，就应该进入这一阶段。 在这个阶段，会有更多参与者提供反馈。这时，参与者有理由相信这个规范不会突然发生重大变化，因此他们更有可能投入时间来进行审核和讨论。 这个阶段至少应持续 45 天，以便收集反馈。 Proposed （提议）/Last Call （最后一次征求意见）一旦参与者认为这个规范已经非常稳定，不会再进行修改，就应该进入这一阶段。 在这个阶段，这个规范会被推给更多参与者来征求意见。之后，这个规范就得到最终确定，无法再进行修改。【「errata （kan）」 除外，详见下文】 这个阶段应该持续至少 14 天。 如果需要进细微调整，可以在不改变当前状态的情况下进行，否则必须回退到 「Candidate」 状态。 特殊要求：frontmatter 中必须带有 Final （敲定）如果 「Proposed」 状态的规范成功通过，就会最终敲定下来。 Withdrawn （撤销）除了 「Final」 和 「Living」 之外，其它所有状态都有可能变成这个状态。 特殊要求：以下几种情况可能会导致 「Withdrawn」 状态，但是必须带有
Living （生效）/Active （激活）那些作为注册表的 EIP-1 以及其它特殊的 EIP 都会被标记为这个状态，因为它们永远也不会被敲定。 任何新的注册文件必须经历完整的 EIP 流程，然后才会变成 「Living」 状态。 Archived （存档）虽然这不是一个状态，但是通过这种方法，可以将撤销了很久的 EIP 移除，以免堆满 EIP 库。点击此处，了解详情。 Obsolete （淘汰）这不是一个状态，而是从 RFC 那里借鉴的淘汰流程。该流程会引入两个字段： (责任编辑：admin) |