diff --git a/rendered/zip-0000.html b/rendered/zip-0000.html index a0be30265..94b62f3b6 100644 --- a/rendered/zip-0000.html +++ b/rendered/zip-0000.html @@ -48,7 +48,8 @@
  • if it affects the consensus layer or the core protocol, assign a number in the range 200..299;
  • if it affects only higher layers but is needed for interoperability between node implementations or other parts of the ecosystem, assign a number in the range 300..399;
  • if it is specific to an implementation (e.g. zcashd or zebra), assign a number in the range 400..499;
    • -
  • if it concerns Consensus Process, assign a number in the range 0..9 or above 1000;
    • +
  • if it concerns Consensus Process, assign a number in the range 0..9 or 1000..1199;
    • +
  • if it only describes updates to existing ZIPs and/or the Zcash Protocol Specification (that will be a complete specification in themselves after deployment), assign a number in the range 2000..2999.
  • try to number ZIPs that should or will be deployed together consecutively (subject to the above conventions), and in a coherent reading order.

    • These conventions are subject to change by consensus of the ZIP Editors.

    @@ -89,11 +90,22 @@

    For each new ZIP that comes in, the ZIP Editors SHOULD:

    +

    For proposals to revise an existing ZIP, the ZIP Editors SHOULD:

    + +

    If an Update ZIP is accepted, it is the responsibility of the ZIP Editors to apply the changes it describes to any existing specifications, but this MUST only be done once the Status of the Update ZIP has reached at least Proposed.

    +

    If a new Revision is added to a ZIP, then its original deployment is called Revision 0. In some cases the revisions of a ZIP may have differing deployment Status, which is expressed in the Status field as described in ZIP Status Field below.

    Reviewing a ZIP

    Any ZIP Editor can suggest changes to a ZIP. These suggestions are the opinion of the individual ZIP Editor. Any technical or process review that ZIP Editors perform is expected to be independent of their contractual or other relationships.

    @@ -115,7 +127,7 @@

    Rejecting a ZIP or update

    The ZIP Editors MAY reject a new ZIP or an update to an existing ZIP, by consensus among the current Editors. Rejections can be based on any of the following reasons:

    -

    All communications should abide by the Zcash Code of Conduct 4 and follow the GNU Kind Communication Guidelines 5.

    +

    All communications should abide by the Zcash Code of Conduct 4 and follow the GNU Kind Communication Guidelines 5.

    ZIP Editor Meeting Practices

    The ZIP Editors SHOULD meet on a regular basis to review draft changes to ZIPs. Meeting times are agreed by consensus among the current ZIP Editors. A ZIP Editor meeting can be held even if some ZIP Editors are not available, but all Editors SHOULD be informed of significant decisions that are likely to be made at upcoming meetings.

    @@ -161,7 +173,7 @@

    ZIP format and structure

    -

    ZIPs SHOULD be written in reStructuredText 6, Markdown 7, or LaTeX 8. For ZIPs written in LaTeX, a Makefile MUST be provided to build (at least) a PDF version of the document.

    +

    ZIPs SHOULD be written in reStructuredText 6, Markdown 7, or LaTeX 8. For ZIPs written in LaTeX, a Makefile MUST be provided to build (at least) a PDF version of the document.

    Each ZIP SHOULD have the following parts:

    ZIP stubs

    -

    A ZIP stub records that the ZIP Editors have reserved a number for a ZIP that is under development. It is not a ZIP, but exists in the ZIPs git repository 9 at the same path that will be used for the corresponding ZIP if and when it is published. It consists only of a preamble, which MUST use Reserved as the value of the Status field.

    +

    A ZIP stub records that the ZIP Editors have reserved a number for a ZIP that is under development. It is not a ZIP, but exists in the ZIPs git repository 9 at the same path that will be used for the corresponding ZIP if and when it is published. It consists only of a preamble, which MUST use Reserved as the value of the Status field.

    ZIP stubs can be added and removed, or replaced by the corresponding ZIP, at the discretion of the ZIP Editors. If a ZIP stub is removed then its number MAY be reused, possibly for an entirely different ZIP.

    ZIP header preamble

    @@ -288,6 +300,12 @@
  • Final: When a Consensus or Standards ZIP is both implemented and activated on the Zcash network.
  • Obsolete: The status when a ZIP is no longer relevant (typically when superseded by another ZIP).
    • +

    If a ZIP has multiple Revisions, they may have differing deployment status. In that case the status of every Revision SHOULD be specified, using the format "[Revision 0] <Status-0>, [Revision 1] <Status-1>, ..." where "<Status-n>" is one of the alternatives above.

    +

    Once any Revision has been Released (as defined in the next section), all subsequent Revisions MUST also be at least Proposed (that is, they MUST NOT be Reserved or Draft). For example, a status such as:

    +
    +

    [Revision 0] Final, [Revision 1] Draft

    +
    +

    is not valid, because changes that are in Draft should not have been applied yet.

    Specification of Status Workflow

    Owners of a ZIP MAY decide on their own to change the status between Draft or Withdrawn. All other changes in status MUST be approved by consensus among the current ZIP Editors.

    A ZIP SHOULD only change status from Draft (or Rejected) to Proposed, when the Owner deems it is complete and there is rough consensus on the forums, validated by consensus among the current ZIP Editors. If it's a Consensus ZIP, a Deployment section MUST be present in order for the ZIP to change status to Proposed. Typically, although not necessarily, this will specify a network upgrade in which the consensus change is to activate.

    @@ -298,6 +316,7 @@

    A Process or Informational ZIP SHOULD change status from Proposed to Active when it achieves rough consensus on the forum or PR. Such a proposal is said to have rough consensus if it has been substantially complete and open to discussion on the forum or GitHub PR for at least one month, has been in Proposed status for at least one week, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections can be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning MUST be given in such circumstances.

    When an Active, Implemented, or Final ZIP is no longer relevant –for example because its implementation has fallen out of use or its process is no longer followed– its status SHOULD be changed to Obsolete. This change MUST also be objectively verifiable and/or discussed. Final ZIPs MAY be updated; the specification is still in force but modified by another specified ZIP or ZIPs (check the optional Updated-By header).

    If a non-editorial update is made to an Obsolete, Withdrawn, or Rejected ZIP, its status MUST be changed appropriately.

    +

    The above process also applies to any subsequent Revisions of a ZIP.

    ZIP Comments

    diff --git a/zips/zip-0000.rst b/zips/zip-0000.rst index b777f9701..5bc024980 100644 --- a/zips/zip-0000.rst +++ b/zips/zip-0000.rst @@ -133,7 +133,11 @@ ZIPs: * if it is specific to an implementation (e.g. zcashd or zebra), assign a number in the range 400..499; * if it concerns Consensus Process, assign a number in the range 0..9 - or above 1000; + or 1000..1199; +* if it only describes updates to existing ZIPs and/or the Zcash + Protocol Specification (that will be a complete specification in + themselves after deployment), assign a number in the range + 2000..2999. * try to number ZIPs that should or will be deployed together consecutively (subject to the above conventions), and in a coherent reading order. @@ -229,13 +233,46 @@ For each new ZIP that comes in, the ZIP Editors SHOULD: * Read the ZIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted. -* Check that the title accurately describes the content. -* Ensure that the ZIP draft has been sent to the Zcash Community Forum - and as a PR to the ZIPs git repository [#zips-repo]_. +* Check that the Title, Category, and other metadata fields accurately + describe the content. +* Ensure that the ZIP draft has been submitted as a PR to the ZIPs git + repository [#zips-repo]_. In some cases it may also be appropriate + for it to be sent to the Zcash Community Forum. * Ensure that motivation and backward compatibility have been addressed, if applicable. * Check that the licensing terms are acceptable for ZIPs. +For proposals to revise an existing ZIP, the ZIP Editors SHOULD: + +* Read the proposed modification to check if it is ready: sound, + complete, and non-disruptive to the ZIP's existing deployments if any. +* If the proposed changes primarily affect already-deployed aspects + of the Zcash consensus protocol, they SHOULD be specified in an + "Update ZIP" describing the changes to be made, rather than directly + as a pull request modifying the existing ZIP(s) or the Zcash Protocol + Specification. At the discretion of the ZIP Editors, this might not + be needed for compatible changes or clarifications. +* If a change is to be made to an existing ZIP, check that the Title, + Category, and other metadata fields still accurately describe the + modified content. +* Ensure that the update has been submitted as a PR to the ZIPs git + repository [#zips-repo]_. In some cases it may also be appropriate + for it to be sent to the Zcash Community Forum. +* Ensure that motivation and backward compatibility have been + addressed, if applicable. +* Check that the licensing terms are still acceptable for ZIPs. + +If an Update ZIP is accepted, it is the responsibility of the ZIP Editors +to apply the changes it describes to any existing specifications, but +this MUST only be done once the Status of the Update ZIP has reached at +least Proposed. + +If a new Revision is added to a ZIP, then its original deployment is +called Revision 0. In some cases the revisions of a ZIP may have +differing deployment Status, which is expressed in the Status field as +described in `ZIP Status Field`_ below. + + Reviewing a ZIP --------------- @@ -624,6 +661,21 @@ ZIP Status Field * Obsolete: The status when a ZIP is no longer relevant (typically when superseded by another ZIP). +If a ZIP has multiple Revisions, they may have differing deployment +status. In that case the status of every Revision SHOULD be specified, +using the format "[Revision 0] , [Revision 1] , ..." +where "" is one of the alternatives above. + +Once any Revision has been Released (as defined in the next section), +all subsequent Revisions MUST also be at least Proposed (that is, +they MUST NOT be Reserved or Draft). For example, a status such as: + + [Revision 0] Final, [Revision 1] Draft + +is not valid, because changes that are in Draft should not have been +applied yet. + + Specification of Status Workflow -------------------------------- @@ -679,6 +731,8 @@ another specified ZIP or ZIPs (check the optional Updated-By header). If a non-editorial update is made to an Obsolete, Withdrawn, or Rejected ZIP, its status MUST be changed appropriately. +The above process also applies to any subsequent Revisions of a ZIP. + ZIP Comments ============