什么是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…