2019 年 6 月，我們就已經深入討論過 EIP 流程的複雜性。如果考慮到每個狀態，則整個 EIP 流程（在 “Deferred” 狀態被移除之前）如下圖所示：
當時，我自己假設 EIP 可以從 “Last Call(最後一次徵求意見)” 狀態轉向 “Abandoned” 狀態，雖然文件裡面沒有這麼寫。
我沒有提到的是，有兩種流程不同的 EIP，而且並非以上所有組合都是有效的。
“核心” EIP 的流程如下所示：
這裡要特別說明的是，“核心” EIP 直到最近才引入 “Last Call” 狀態。
“非核心” EIP 的流程如下所示：
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 上的頻道討論和評議構想。
Draft（草案）
假設某個構想引起了人們的興趣，我們就應該基於 EIP 模版為其建立草案。只要這個草案符合基本的語法要求，我們就應該將其合併。
問題：關於編輯應有多大的稽覈提案的許可權，人們的觀點各不相同，目前還沒有明確的答案。如果我們有一個良好的流程來移除不成功的 EIP，那麼早一點合併草案無疑是正確的做法。
在這一階段，預期會有一小群感興趣的參與者對草案進行討論。
“Draft” 狀態沒有時間限制，但是建議不要超過合理的時間範圍（幾個月）。
Candidate（候選）/Review（稽覈）
一旦草案足夠穩定，預期不會再進行重大修改，就應該進入這一階段。
在這個階段，會有更多參與者提供反饋。這時，參與者有理由相信這個規範不會突然發生重大變化，因此他們更有可能投入時間來進行稽覈和討論。
這個階段至少應持續 45 天，以便收集反饋。
Proposed（提議）/Last Call（最後一次徵求意見）
一旦參與者認為這個規範已經非常穩定，不會再進行修改，就應該進入這一階段。
在這個階段，這個規範會被推給更多參與者來徵求意見。之後，這個規範就得到最終確定，無法再進行修改。【“errata（kan）” 除外，詳見下文】
這個階段應該持續至少 14 天。
如果需要進細微調整，可以在不改變當前狀態的情況下進行，否則必須回退到 “Candidate” 狀態。
特殊要求：frontmatter 中必須帶有 review-end-date 欄位。
Final（敲定）
如果 “Proposed” 狀態的規範成功透過，就會最終敲定下來。
Withdrawn（撤銷）
除了 “Final” 和 “Living” 之外，其它所有狀態都有可能變成這個狀態。
特殊要求：以下幾種情況可能會導致 “Withdrawn” 狀態，但是必須帶有 reason 欄位：
withdrawn by author：作者在任意階段做出了撤銷決定
withdrawn due to inactivity：作者在一段特定的時間（180 天）內沒有任何活動。
Living（生效）/Active（啟用）
那些作為登錄檔的 EIP-1 以及其它特殊的 EIP 都會被標記為這個狀態，因為它們永遠也不會被敲定。
任何新的註冊檔案必須經歷完整的 EIP 流程，然後才會變成 “Living” 狀態。
Archived（存檔）
雖然這不是一個狀態，但是透過這種方法，可以將撤銷了很久的 EIP 移除，以免堆滿 EIP 庫。點選此處，瞭解詳情。
Obsolete（淘汰）
這不是一個狀態，而是從 RFC 那裡借鑑的淘汰流程。該流程會引入兩個欄位：
obsoleted-by：包含一個將當前 EIP 淘汰的 EIP 編號
obsoletes：包含一組被當前 EIP 淘汰的 EIP 編號
只有在處於 Final 或 Withdrawn 狀態時，當前 EIP 才能使用 obsoleted-by 欄位。
只有被引用 EIP 的 “obsoleted-by” 欄位指向當前 EIP 時，當前 EIP 才能帶有 obsoletes 欄位。
這就意味著，作為淘汰方和被淘汰方 EIP 的作者必須達成共識。鑑於有人提議了一個更好的淘汰流程，這一點未來可能會發生變化。
Errata（勘誤）
按照慣例，小的打字錯誤可由編輯修改。
按理來說，任意能幫助闡明規範的修改都可以接受，只要它不至於使原提案面目全非，因為小的修改可以在 Errata 部分做出解釋。如果需要重大修改，必須淘汰相應的 EIP，並重新建立一個 EIP 。
Remark
以下 frontmatter 欄位被移除，因為它們未經詳細說明 和/或 使用：
· replace （已由淘汰流程取代）
· superseded-by（已由淘汰流程取代）
· resolution
需要這些欄位的話，可以再新增回來。
以下狀態被移除：
· Abandoned（重新命名為 “Withdrawn”）
· Rejected
· Accepted
· Superseded（已由淘汰流程取代）
工具
然而，EIP 面臨的最大挑戰是需要人力。
最近，舊版本的格式校驗器 eip_validator 已經換成了更好的版本 eipv。另外，我們已經啟動了一個機器人來檢查過時 PR 的問題。
雖然有了工具的輔助，編輯和審校依然需要投入大量的人力。如果我們想要讓 EIP 流程變得更加流暢，就要使用機器人來代替真人完成大部分工作。我已經建立了一個新的議題來討論 EIP 庫需要引入哪些機器人。
有志願者想要一起實現機器人嗎 : ) : )
