From 0c8acb147dd155c36f4968c87e56a9eb43a9607b Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Thu, 14 Sep 2023 10:27:00 +0100 Subject: [PATCH] ZIP 0 clarifications: * Remove redundancy between the list of reasons to reject an update and the "Specification of Status Workflow" section, and move things to the right section. * Define "Released". * Remove use of "proposed" (which was not intended to be the same as the status "Proposed"). * Add another reason to reject an update: it violates a conformance requirement of any Active Process ZIP (including this ZIP); * Clarify that ZIP stubs, and only ZIP stubs, MUST use Status: Reserved; * Clarify when a Released ZIP can be changed to a non-Released status; * Require that changes in status other than Draft <-> Withdrawn in general need consensus among ZIP Editors, and eliminate resulting redundancies. This is technically a strengthened requirement for changes other than to Proposed or Rejected, but reflects existing practice. * Clarify how the Owners of a ZIP change it to Withdrawn. * Active can now only be reached from Proposed. Strengthen the requirements for rough consensus in this case to say that the ZIP has been complete for at least a month and Proposed for at least a week. This will impose a bit more overhead but I think it's necessary; previously, a Process or Informational ZIP could have gone directly from Draft to Active without sufficient notice. * Require that a Consensus ZIP has an implementation merged into at least one consensus node codebase (currently zcashd and/or zebra) before it is moved to Implemented, and make the existing discussion of timing relative to a network upgrade apply only to Consensus ZIPs; * Require that if a non-editorial update is made to an Obsolete or Withdrawn ZIP, its status MUST be changed appropriately. * Allow a status transition from Implemented to Obsolete, and clarify when transitions to Obsolete occur. * Add a responsibility for the ZIP Secretary to share significant changes in ZIP status, in particular progression of a ZIP to Proposed, on the Community Forum. Signed-off-by: Daira Emma Hopwood --- zip-0000.rst | 107 ++++++++++++++++++++++++++++++--------------------- 1 file changed, 63 insertions(+), 44 deletions(-) diff --git a/zip-0000.rst b/zip-0000.rst index ffabd78d..b6c9c712 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -260,10 +260,10 @@ When a ZIP is ready, the ZIP Editors will: The ZIP editors monitor ZIP changes and update ZIP headers as appropriate. -Rejecting a proposed ZIP or update ----------------------------------- +Rejecting a ZIP or update +------------------------- -The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP, +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: @@ -279,12 +279,10 @@ of the following reasons: * it includes buggy code, pseudocode, or algorithms; * it manifestly violates common expectations of a significant portion of the Zcash community; -* it updates a Draft ZIP to Released when there is significant community - opposition to its content (however, Draft ZIPs explicitly may describe - proposals to which there is, or could be expected, significant community - opposition); -* in the case of a Released ZIP, the update makes a substantive change to - which there is significant community opposition; +* it updates a ZIP's status, or fails to make a needed status update, in a way + inconsistent with the requirements in `Specification of Status Workflow`_; +* in the case of a Proposed, Active, Implemented, or Final ZIP, the update + makes a substantive change to which there is significant community opposition; * it is dependent on a patent that could potentially be an obstacle to adoption of the ZIP; * it includes commercial advertising or spam; @@ -293,17 +291,17 @@ of the following reasons: if there is one; * an update to an existing ZIP extends or changes its scope to an extent that would be better handled as a separate ZIP; -* a new ZIP has been proposed for a category that does not reflect its content, - or an update would change a ZIP to an inappropriate category; -* it updates a Released ZIP to Draft when the specification is already - implemented and has been in common use; +* a new ZIP has a category that does not reflect its content, or an update + would change a ZIP to an inappropriate category; * it violates any specific "MUST" or "MUST NOT" rule in this document; * the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct [#conduct]_ (except in the case of an update removing that Owner); * it is not authorized by the stated ZIP Owners; * it removes an Owner without their consent (unless the reason for removal - is directly related to a breach of the Code of Conduct by that Owner). + is directly related to a breach of the Code of Conduct by that Owner); +* it violates a conformance requirement of any Active Process ZIP + (including this ZIP). The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal or update that does not violate any of these criteria. If they refuse a @@ -341,7 +339,9 @@ role. The ZIP Secretary will: * share a draft agenda with the ZIP Editors at least 24 hours before each ZIP Editors' meeting; * share draft minutes of significant decisions with the ZIP Editors in the week after the ZIP Editors' meeting; and -* share significant ZIP changes on the Zcash Community Forums. +* share significant ZIP changes, including significant changes of status (in + particular, progression of a ZIP to Proposed status), on the Zcash Community + Forum. If the draft agenda is empty, any ZIP Editor MAY submit agenda items, or suggest that the meeting is cancelled. @@ -448,7 +448,7 @@ 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 [#zips-repo]_ at the same path that will be used for the corresponding ZIP if and when it is published. It consists only of a -preamble. +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 @@ -583,26 +583,25 @@ ZIP Status Field * Reserved: The ZIP Editors have reserved this ZIP number, and there MAY be a Pull Request for it, but no ZIP has been published. The ZIP Editors SHOULD publish a stub header so that the reservation appears in the - `ZIP index `__. + `ZIP index `__. This status MUST + only be used for ZIP stubs. * Draft: All initial ZIP submissions have this status. -* Withdrawn: If the Owner decides to remove the ZIP from - consideration by the community, they may set the status to Withdrawn. +* Withdrawn: The Owners of a ZIP MAY remove it from consideration by + the community, by changing its status to Withdrawn (in a PR or by + request to the ZIP Editors). -* Active: Typically only used for Process/Informational ZIPs, achieved - once rough consensus is reached in PR/forum posts from Draft Process ZIP. +* Active: Typically only used for Process or Informational ZIPs, achieved + once rough consensus on a Proposed ZIP is reached in PR/forum posts. * Proposed: Typically the stage after Draft, added to a ZIP after consideration, feedback, and rough consensus from the community. - The Proposed status MUST be approved by consensus among the current - ZIP Editors. * Rejected: If no progress on a Draft or Proposed ZIP has been made for - one year, the ZIP Editors SHOULD move it to Rejected status. It can revert - back to Draft/Proposed if the Owner resumes work or resolves issues - preventing consensus. The Rejected status MUST be approved by - consensus among the current ZIP Editors. + one year, the ZIP Editors SHOULD move it to Rejected status. It can + revert back to Draft or Proposed if the Owners resume work or resolve + issues preventing consensus. * Implemented: When a Consensus or Standards ZIP has a working reference implementation but before activation on the Zcash network. @@ -619,7 +618,8 @@ Specification of Status Workflow -------------------------------- Owners of a ZIP MAY decide on their own to change the status between -Draft or Withdrawn. +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 @@ -628,27 +628,46 @@ 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. -A Standards ZIP SHOULD only change status from Proposed to Implemented once -the Owners provide an associated reference implementation, typically in -the period after the network upgrade's specification freeze but before +A ZIP's status is Released if it is Proposed, Active, Implemented, or Final +(i.e. not Draft, Rejected, Obsolete, or Withdrawn). + +A ZIP SHOULD NOT be changed from a non-Released status to a Released +status if there is significant community opposition to its content. +(However, Draft ZIPs explicitly MAY describe proposals to which there +is, or could be expected, significant community opposition.) + +A Released ZIP MUST NOT be changed to a non-Released status if the +specification is already implemented and is in common use, or where a +Process ZIP still reflects a consensus of the community. + +A Standards ZIP SHOULD only change status from Proposed to Implemented +once the Owners provide an associated reference implementation. For +Consensus ZIPs, an implementation MUST have been merged into at least +one consensus node codebase (currently zcashd and/or zebra), typically +in the period after the network upgrade's specification freeze but before the implementation audit. If the Owners miss this deadline, the Editors or Owners MAY choose to update the Deployment section of the ZIP to target another upgrade, at their discretion. -A Process or Informational ZIP SHOULD change status from Draft 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 open to discussion on the -forum or GitHub PR for at least one month, 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. +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 or Final ZIP is no longer relevant, 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). +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. ZIP Comments