diff --git a/zip-0000.rst b/zip-0000.rst index 1157e648..afc9e7d7 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -31,9 +31,9 @@ technical specification of the feature and a rationale for the feature. We intend ZIPs to be the primary mechanism for proposing new features, for collecting community input on an issue, and for documenting the -design decisions that have gone into Zcash. The author(s) of the ZIP -(known as Owners in this document) are responsible for building -consensus within the community and documenting dissenting opinions. +design decisions that have gone into Zcash. The Owner(s) of the ZIP +(usually the authors(s)) are responsible for building consensus within +the community and documenting dissenting opinions. Because the ZIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. @@ -50,18 +50,17 @@ The ZIP process begins with a new idea for Zcash. Each potential ZIP must have a Owner -- someone who writes the ZIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The -ZIP Owner (a.k.a. author) should first attempt to ascertain whether -the idea is ZIP-able. Small enhancements or patches to a particular -piece of software often don't require standardisation between multiple -projects; these don't need a ZIP and should be injected into the -relevant project-specific development workflow with a patch submission -to the applicable issue tracker. Additionally, many ideas have been -brought forward for changing Zcash that have been rejected for various -reasons. The first step should be to search past discussions to see if -an idea has been considered before, and if so, what issues arose in its -progression. After investigating past work, the best way to proceed is -by posting about the new idea to the `Zcash Community Forum -`__. +ZIP Owner should first attempt to ascertain whether the idea is ZIP-able. +Small enhancements or patches to a particular piece of software often +don't require standardisation between multiple projects; these don't +need a ZIP and should be injected into the relevant project-specific +development workflow with a patch submission to the applicable issue +tracker. Additionally, many ideas have been brought forward for changing +Zcash that have been rejected for various reasons. The first step should +be to search past discussions to see if an idea has been considered +before, and if so, what issues arose in its progression. After +investigating past work, the best way to proceed is by posting about the +new idea to the `Zcash Community Forum `__. Vetting an idea publicly before going as far as writing a ZIP is meant to save both the potential Owner and the wider community time. Asking @@ -130,6 +129,10 @@ Editors. If the original Owner doesn't respond to email in a timely manner, the ZIP Editors will make a unilateral decision (it's not like such decisions can't be reversed :). +If an author of a ZIP is no longer an Owner, an Original-Authors field +SHOULD be added to the ZIP metadata indicating the original authorship, +unless the original author(s) request otherwise. + ZIP Editors ----------- @@ -278,9 +281,9 @@ Each ZIP SHOULD have the following parts: * Reference implementation -- Literal code implementing the ZIP's specification, and/or a link to the reference implementation of the ZIP's specification. The reference implementation must be - completed before any ZIP is given status “Implemented”, but it - generally need not be completed before the ZIP is accepted into - Proposed. + completed before any ZIP is given status “Implemented” or “Final”, + but it generally need not be completed before the ZIP is accepted + into “Proposed”. ZIP header preamble ------------------- @@ -298,6 +301,8 @@ header fields are REQUIRED:: The following additional header fields are OPTIONAL:: + Credits: + Original-Authors:  Discussions-To:  Network Upgrade: Obsoleted by: