摘要：所提出的改善提案必須是一個清晰和完整的描述。當實現完成并被社區采納時，狀態將改為結束。它應該清楚地解釋現有的協議規范的不足以及解決的問題。沒有充分動機的提案可能被徹底拒絕。

什么是NEP

NEP基本原理

NEP類型

NEP工作流程

怎么才是一個合格的NEP

NEP格式和模板

NEP序言
附件

NEP所有權轉讓

NEP編輯者

NEP編輯者的職責和工作流程

歷史

什么是NEP

NEP是NEO改進協議。一份NEP是一份設計文檔用于給給NEO社區提供信息，或是描述一個NEO的新特性或其工序或環境。NEP需要對特性提供一份簡要的技術說明以及基本原理。NEP的作者有責任在社區內構建輿論和編輯不同的觀點

NEP基本原理

我們計劃NEP的主要作用是提出新特性，收集社區中關于某個問題的觀點和整理歸納引進到NEO中的設計決定。由于NEP作為版本文件存儲在版本化的存儲庫中，它們的版本歷史是特性提案的歷史記錄。
對于NEO的實施者，NEP是一種便捷的方式來追蹤他們的實施進度。理想情況下，每個實施維護人員都會列出他們的NEP。如此會使終端使用者很方便的了解某個實現或者庫的狀態。

NEP類型

有三種類型的NEP：
·一份標準路線 NEP描述任何會影響多數NEO實施者的影響，例如一個網絡協議的改變，一個區塊或者交易有效性規則的改變，擬議應用標準/公約，或者任何會影響應用使用NEO操作性的改變或者添加
·一份信息類 NEP描述一個NEO的設計問題，或提供指給社區指南或者信息，但是并不提議一個新特性。信息類的NEP并不必然代表一個NEO社區的共識或者推薦，所以使用者或者實施者可以自由的忽略信息類的NEP或跟隨建議
·一份元NEP描述了一個圍繞NEO的工序流程，或者提出了一個工序流程（或事項目）的改變。元NEPS類似于標準路線NEP，但適用于除NEO協議本身之外的區域。他們可能提出一個實現，但不提到NEO的代碼庫；他們需要社區的共識；與信息類NEP不同，它們不僅僅是建議，而且用戶通常不能自由地忽略它們。示例包括流程、指南、決策過程的更改，以及NEO開發中使用的工具或環境的更改。

NEP工作流程

一個NEP的流程開始于一個關于NEO的新想法。強烈建議一個單一的NEP包含一個單一的關鍵流程或新想法。多關注NEP就越容易成功。對于單一客戶端的變動不需要一個NEP，但可能影響多客戶端的改變或者定義多個app應用標準則需要。NEP編輯者有權拒絕NEP提案，如果它們顯得過于不集中或過于寬泛。如果有疑問，把你的NEP分成幾個比較集中的。
每個NEP必需有個擁護者—使用以下描述的風格和格式編寫NEP的人，在的論壇中適當的指導討論，并試圖圍繞這個想法建立社區共識。
在寫一個NEP前先公開審查一下想法意味著節約了作者的潛在時間。先向NEO社區詢問一個想法是否具有原創性有助于防止花費太多時間在基于先前討論而保證被否定的事情上（搜索因特網并不總是奏效）。它也有助于確定這個想法適用于整個社區，而不僅僅是作者。僅僅因為一個想法對作者來說聽起來不錯，并不意味著它對使用NEO的各領域的大多數人都有效。通過合適的論壇來評估NEP，包括NEO子版、倉庫的問題部分和NEO閑置通道之一。特別的，倉庫的問題部分非常適合與社區討論你的提議并開始創建一些有有關于你的NEP的正式言論。

一旦擁護者向近NEO社區詢問一個想法是否有任何機會被接納為NEP草案這給了作者一個連續編輯NEP草稿的機會，用于正確的格式和質量。這也允許進一步的公眾評論和NEP的作者來關注這個提案。

如果NEP的協作者同意，NEP編輯者會給NEP分配一個數字，標記它是標準、信息、或是元，并給它狀態‘草案’，并將它加入到git倉庫。NEP編輯者不會不合理的否定一個NEP。否定NEP的理由包括重復勞動、技術不健全、不正當動機或向后兼容，或違背NEO的價值觀

標準追蹤型NEP由三部分組成，設計文檔、實現，最后如果需要更新的正式規范。在實施開始之前，NEP需要被審核和采納，除非該實施將有助于人們研究NEP。標準追蹤型NEP必須包含一個實現——以代碼、補丁或URL的形式——在其被認定結束狀態前。

對于一個被接受的NEP，它必須滿足一定的最低標準。所提出的改善提案必須是一個清晰和完整的描述。改善必須是一個純的改進。提案實現，如果適用的話，必須是可靠的并且不能過分復雜化協議。
一旦NEP被采納，就必須完成實現。當實現完成并被社區采納時，狀態將改為“結束”。
NEP也可以被賦予“延期”的狀態。NEP作者或編輯者可以在NEP沒有進展的情況下給NEP分配該狀態。一旦NEP被推遲，NEP編輯者可以重新將其分配成草稿狀態。

NEP也可以被“拒絕”。也許這不是個好主意。記錄這一事實仍然很重要。

NEP也可以被一個不同的NEP替代，使原來的過期。

NEP狀況的可能路徑如下：

一些信息型或元NEP也可能是狀態“活躍”如果他們從未被完成，例如NEP1（本NEP）。

怎么才是一個合格的NEP

每個NEP應該有以下部分：
·序言——RFC 822樣式標頭，包含關于NEP的元數據，包括NEP編號、簡短的描述性標題（限制最多44個字符）、姓名、以及可選的每個作者的聯系人信息等。
·摘要——-一個簡短的（200字）描述正在處理的技術問題。
·動機（*可選）-動機是那些想要改變NEO協議的NEP至關重要的部分。它應該清楚地解釋現有的協議規范的不足以及NEP解決的問題。沒有充分動機的NEP提案可能被徹底拒絕。
·詳述——技術詳述應該描述新特征的語法和語義。該規范應該足夠詳細，以允許針對任何當前NEO平臺的競爭、可互操作的實現。

?基本原理——基本原理詳細說明設計目的以及設計方案的理由。它應該描述相關工作的替代設計，例如在其他語言中如何支持該特性。基本原理也可以提供社區內共同意見的證據，并且應當討論在討論期間提出的重要反對或重點。

·向后兼容性——引入向后兼容性的所有NEP必須包括描述其不兼容性及其嚴重性。NEP必須解釋作者是如何處理這些不兼容性的。沒有足夠的向后兼容性的NEP提交可能被徹底拒絕。

·測試用例——實現的測試用例對于那些會引起共識改變的NEP是必須的。其他NEP可以選擇包括測試用例的鏈接如果需要的化。

·實現——實現必須在任何NEP“完結”狀態前之前完成，但是不需要在NEP受理前完成。最好先完成規范和原理并在編寫代碼之前達成共識。

NEP格式和模板

NEP必需用 mediawiki or markdown格式編寫。圖片文件必需包含在NEP的子目錄。

NEP序言

每個ＮＥＰ必須由一個RFC822格式的頭部欄開始。頭部欄必須包含以下順序。
用*號標示的是可選的，稍后寫介紹。其他都是必須的。
NEP: (由NEP編輯者決定)
Title:
Author:
*Discussions-To:
Status: Final | Superseded>
Type:
Created:
*Replaces:
*Superseded-By:
*Resolution:

作者頭部欄列出NEP的所有作者/所有者的姓名，以及可選的電子郵件地址。作者頭值的格式必須是 Random J. User address@dom.ain有email地址的情況下，Random J. User 沒有email地址的情況下。
如果有多個作者，每一個都應在之后獨立的一行中的遵守RFC2822的協議。

注意：解決方案欄只適用于標準追蹤型NEP。它包含一個URL，該URL應該指向一個電子郵件消息或其他關于NEP的聲明的Web資源。
當NEP處于私下討論階段時（通常在初始草稿階段），Discussions-To欄將指示正在討論NEP的郵件列表或URL。如果NEP處于與作者私下討論階段，則不需Discussions-To欄。
類型欄指定NEP的類型：標準、信息或元。
創建欄記錄了NEP被分配編號的日期。它應該是YYYY-MM-DD格式，例如2001-08-14。
NEPS可能有一個需求欄，指示NEP依賴的NEP編號。
NEP還可以有一個Superseded-By欄，指示NEP已經被后面的文檔淘汰；該值是替換當前文檔的NEP文檔編號。較新的NEP必須有一個替換欄，該欄包含其過時的NEP編號。

附件

NEP可以包括附件，如圖表。此類文件必須包含在該NEP的子目錄中，并命名為nep-x-y.ext，其中“x”是NEP編號，“y”是序列號（從1開始），而“ext”被實際的文件擴展名（例如“png”）替換。

NEP所有權轉讓

有時候需要將NEP所有權轉讓給新的擁護者。一般來說，我們希望保留原作者作為已轉移NEP的合著者，但這取決于原作者。轉移所有權的一個恰當的理由是，因為原始作者不再有時間或興趣更新它，或者繼續執行NEP的流程，或者已經脫離“網絡”的位面（即，無法訪問或不回復電子郵件）。轉移所有權的一個不恰當的原因是因為你不同意NEP的方向。我們試圖在圍繞NEP建立共識，但如果這是不可能的，你可以提交一個競爭的NEP。

如果您有興趣接管NEP的所有權，請向原始作者和NEP編輯者發送請求接管的消息。如果原作者沒有及時回復郵件，NEP編輯者會做出單方面的決定（此類決定并非不能逆轉:）.

NEP編輯者

當前的NEP編輯者是
·Erik Zhang (@erikzhang)

NEP編輯者的職責和工作流程

每收到一份新的NEP，編輯者會做如下事情：
·閱讀NEP檢查它是否完備：健全和完整。想法必需有技術意義，即使它看起來并不能被接受。
·標題必需準確的描述內容。
·編輯NEP的語言（拼寫，語法，句子結構等），標記，代碼風格。

如果NEP并不完備，編輯者會將其退回給作者重新修訂，并給出具體說明
一旦NEP準備好合到倉庫,NEP編輯者會:
·分配一個NEP編號(基本是下一個可用的數字,但有時也可能是一個特殊數字,例如666或者3141)在拉取請求的評論中.
·當作者準備好后合并下拉請求(允許有進一步的同行評審時間).
·在README.mediawiki中列出NEP.
·回復NEP作者告知下一步操作.
NEP編輯者旨在履行管理和編輯的職責.NEP編輯者收集NEP的變化,并改正任何我們看到的結構、語法、拼寫或標記上的額錯誤。

歷史

本文檔是根據Amir Taaki從Python版PEP-0001衍生出的比特幣的BIP-0001文檔編寫的。在許多地方僅是簡單復制和修改。雖然PEP-0001文檔是由Barry Warsaw, Jeremy Hylton, and David Goodger編寫，但是他們并不負責其在NEO改善過程中的使用，并且不用回答任何NEO或者NEP的技術問題。請把所有意見評論直接提交給NEP編輯者。

原文：來自 https://github.com/neo-projec...