NEO改進協議提案1（NEP-1）

文章目錄

• 什麼是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編號>(由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編輯者。

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