什麼是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編號>(由NEP編輯者決定)
Title: <NEP標題>
Author: <list of authors’ real names and optionally, email address>
*Discussions-To: <email地址>
Status: <Draft | Active | Accepted | Deferred | Rejected | Withdrawn |
Final | Superseded>
Type: <Standard | Informational | Meta>
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
*Replaces: <NEP編號>
*Superseded-By: <NEP編號>
*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編輯者。

原文：來自 github.com/neo-project…