mirror of https://github.com/zcash/zips.git
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 <daira@jacaranda.org>
This commit is contained in:
Daira Emma Hopwood
parent
e9469a3d61
commit
0c8acb147d
107
zip-0000.rst
107
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 <https://zips.z.cash#index-of-zips>`__.
|
||||
`ZIP index <https://zips.z.cash#index-of-zips>`__. 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
|
||||
|
|
|
|||
Loading…
Reference in New Issue