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: