README-CN.md

GXIP: 0001
Title: GXChain改进提案目的和指南
Authors: David Lan <[email protected]>
Status: Draft
Type: Informational
Created: 2018-11-13

什么是 GXIP?

GXIP代表GXChain改进提案，但也可以视为改进协议。 GXIP是一个设计文档，向GXChain社区提供信息，或描述GXChain或其流程或环境的新功能。 GXIP应提供有关特征或想法的简明技术规范及其理由。它不仅可以描述技术改进，还可以记录最佳实践和建议。

我们打算将GXIPs作为提出新功能，收集社区对问题的意见以及记录GXChain设计决策的主要机制。 GXIP作者负责在社区内建立共识并记录不同意见。

由于GXIP在版本化存储库中作为文本文件维护，因此其修订历史记录是功能提议的历史记录。

GXIP有哪些类型

GXIP分为两种：

• 信息类GXIP描述GXChain设计问题，或向GXChain社区提供一般指南或信息，但不提议新功能，协议更改或任何其他修改。信息类GXIP不一定代表GXChain社区的共识或建议，因此用户和实施者可以自行选择是忽略信息类GXIP还是遵循他们的建议。比如最佳实践或建议。

• 协议升级类GXIP描述影响大多数或所有GXChain实施的变更，例如协议的更改，块或事务有效性规则的更改，或影响使用GXChain的应用程序的互操作性的任何更改及添加。

如何参与贡献

希望提交GXIP的人应首先在issue中提出他们的想法。讨论结束后，将获得一个gxip的编号，以这个编号为目录名提交状态为draft(草稿)Pull Request。一旦达成讨论参与者之间的共识，状态将变更为Accept(接受)。自此，不允许对文件进行重大更改。

如果提案需要协议升级，则只有在社区参与者批准了相应的工作人员或硬分叉提案时，才会考虑实施。信息类GXIP只能达到接受状态后才考虑实施，因为这类提案我们不强制执行它们

我们在这里列出GXIP草案完全自主的，因为其实际实施的最终决定是由GXChain社区参与者通过批准投票完成的。

强烈建议单个GXIP包含单个关键提议或新想法。小的增强或补丁通常不需要GXIP，可以通过向GXChain问题跟踪器提交补丁，将其注入GXChain开发工作流程。 GXIP越集中，它就越成功。 如果GXIP看起来太过分散或太宽泛，编辑人员保留拒绝GXIP提案的权利。如果有疑问，请将您的GXIP分成几个注重焦点的GXIP。

在编写GXIP之前公开征求一个想法是为了节省潜在的修改时间。此前有许多改变GXChain的想法，都因为各种原因被拒绝了。所以，请首先询问GXChain社区你的想法是否是原创的，这有助于防止花费太多时间在讨论在此前已经被拒绝的事情上（搜索互联网并不总是那么有效）。它还有助于确保该想法适用于整个社区而不仅仅是作者。一个想法对作者来说听起来不错并不意味着它适用于大多数使用GXChain的大多数人。

在讨论之后，该提案应该通过GXIP草案形式发送给GXChain开发人员和GXIP编辑人员。该草案必须以如下所述GXIP格式编写，否则将会被打回。

在GXIP编辑人员批准之后，他将为GXIP分配一个编号，标记它的状态为“draft”(草稿)，并将其添加到git仓库。 GXIP编辑人员不会无理拒绝GXIP。拒绝GXIP状态的原因包括重复工作，技术上不健全，没有提供适当的动机或解决向后兼容性，或者不符合GXChain理念。

GXIP作者可以根据需要在git仓库中更新草案。作者也可以通过提交Pull Request的方式对草案进行更新。

被接受的GXIP，它必须符合某些最低标准。它必须包含对提议改善的清晰和完整的描述。这些改动必须是净改善。如果适用，拟议的实施必须是可靠的，不得使协议复杂化。

GXIP发布后，必须完成参考实施部分。当参考实施完成并由股东通过批准投票接受时，状态将更改为“已接受”。 GXIP也可能被社区“拒绝”。

此外，GXIP可以被指定为“延期”状态。当GXIP没有取得进展时，GXIP作者或编辑人员可以为GXIP分配此状态。延迟GXIP后，GXIP编辑者可以将其重置为草稿状态。

GXIP也可以被不同的GXIP取代，使原始的过时。这适用于信息类GXIP，比如API的第2版可以替换版本1。

GXIP包含哪些内容

每个GXIP 必须 包含以下几个部分:

• Preamble(前言) -- RFC 822 格式的包含GXIP元信息描述的的头部信息，包括GXIP编号、一个简短的标题（限制在44个字符内）、命名，也可以附加作者的联系方式等

• Abstract(概要) -- 简短地描述正在解决的技术问题 (约200字左右)

• Copyright/public domain(版权/公共域) -- 每个GXIP必须明确标记为放置在公共域中（请参阅此GXIP作为示例）或根据开放出版许可证获得许可。

• Motivation(动机) -- 对于想要更改GXChain协议的GXIP，动机至关重要。它应该清楚地解释为什么现有的协议规范不足以解决GXIP解决的问题。没有足够动机的GXIP提交可能会被彻底拒绝。

• Rationale(合理性描述) -- 通过阐述原因和动机来论证观点。这部分内容应该描述可以选择的几种设计方案，以及涉及的相关工作。比如，如何在其他语言中支持该功能。合理性描述部分应该提供社区内共识的证据，并讨论在此前讨论中提出的重要异议或关注点。

• Specification(规范) -- 技术规范应描述任何新功能的语法和语义。规范应该足够详细，以允许任何当前GXChain平台的竞争性和互操作性的实现。

• Discussion(讨论) -- GXIP应包括对GXChain生态系统的正面和负面影响的讨论，并由社区接受。本节应该是股东最重要的部分，以便掌握GXIP的全部影响并帮助社区做出决策。

• Summary for Shareholders(意见总结) -- 大多数GXIP可能具有技术性质。但是，许多股东并不像特定GXIP的作者那样具有技术能力。这个非技术性段落可以用来与股东互动并帮助他们形成自己的观点。然而，这并不意味着在此给股东提出支持或反对提案的指导性意见。

GXIP 格式和模板

GXIPs 应该通过markdown语法来书写. 图片文件应该被包含在GXIP对应的子目录中，在本仓库中我们提供了一个包含前言的模板。

GXIP 编辑人员

当前的编辑人员有:

• Albert [email protected]
• David Lan [email protected]

编辑人员不会对GXIPs的内容做出判断。我们只做行政和编辑部分。

许多GXIP由具有GXChain代码库写入权限的开发人员编写和维护。 GXIP编辑人员监控GXIP的变化，并纠正看到的任何结构，语法，拼写或标记错误。

对于每个新GXIP编辑人员会做以下事情：

• 阅读GXIP以检查它是否是内容完整的。这些想法必须具有技术意义，即使它们似乎不太可能被接受。
• 标题应准确描述内容。
• 组织GXIP语言（拼写，语法，句子结构等），标记（对于reST GXIPs），代码样式。

当一个GXIP准备好被提交到仓库时，应该以Pull Request的方式提交到gxchain/gxips，在这里可以获得后续的反馈

此时，GXIP编辑人员将做以下几件事情:

• 在GXIP的Pull Request评论区分配一个编号，通常这个编号是自增的，有时也可能是一个特殊的编号（例如666或3141）
• 在作者准备好时合并Pull Requst（允许一些时间进行进一步的同行评审）
• 在README.md中列出这个GXIP
• 把后续步骤通过电子邮件发给GXIP作者（发布到GXChain邮件列表）。

历史

本文档源自Python的PEP-0001和比特币BIP-0001。在许多地方，文本只是被复制和修改。尽管PEP-0001 / BIP-0001文本由Barry Warsaw，Jeremy Hylton和David Goodger编写，但他们对GXChain改进过程中的使用不负责任，并且不必GXChain或GXIP特有的技术问题做出回应。请将所有意见直接发送给GXIP编辑人员或GXChain开发组邮件列表。