文章目录
什么是 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 序言
每个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…