zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

s/Champion/Owner/g 

Co-authored-by: Josh Cincinnati <acityinohio@users.noreply.github.com>
This commit is contained in:
Daira Hopwood 2019-03-20 03:02:47 +00:00
parent d22670e43a
commit f61e720c02
1 changed files with 39 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

79
zip-0000.rst
View File

@ -2,8 +2,8 @@
ZIP: 0
Title: ZIP Process
Champions: Daira Hopwood
Josh Cincinnati
Owners: Daira Hopwood
Josh Cincinnati
Status: Draft
Type: Process
Created: 2019-02-16
@ -32,7 +32,7 @@ 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 Champions in this document) are responsible for building
(known as Owners in this document) are responsible for building
consensus within the community and documenting dissenting opinions.
Because the ZIPs are maintained as text files in a versioned repository,
@ -47,10 +47,10 @@ ZIP Workflow
============
The ZIP process begins with a new idea for Zcash. Each potential ZIP
must have a Champion -- someone who writes the ZIP using the style and
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 Champion (a.k.a. author) should first attempt to ascertain whether
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
@ -64,29 +64,29 @@ by posting about the new idea to the `Zcash Ecosystem Development
list <https://lists.z.cash.foundation/mailman/listinfo/zcash-ecosystem-dev>`__.
Vetting an idea publicly before going as far as writing a ZIP is meant
to save both the potential Champion and the wider community time. Asking
to save both the potential Owner and the wider community time. Asking
the Zcash community first if an idea is original helps prevent too much
time being spent on something that is guaranteed to be rejected based on
prior discussions (searching the internet does not always do the trick).
It also helps to make sure the idea is applicable to the entire
community and not just the Champion. Just because an idea sounds good to
the Champion does not mean it will work for most people in most areas
community and not just the Owner. Just because an idea sounds good to
the Owner does not mean it will work for most people in most areas
where Zcash is used.
Once the Champion has asked the Zcash community as to whether an idea
Once the Owner has asked the Zcash community as to whether an idea
has any chance of acceptance, a draft ZIP should be presented to the
`Zcash Ecosystem Development list
<https://lists.z.cash.foundation/mailman/listinfo/zcash-ecosystem-dev>`__.
This gives the Champion a chance to flesh out the draft ZIP to make it
This gives the Owner a chance to flesh out the draft ZIP to make it
properly formatted, of high quality, and to address additional concerns
about the proposal. Following a discussion, the proposal should be
submitted to the `ZIPs git repository <https://github.com/zcash/zips>`__
as a pull request. This draft must be written in ZIP style as described
below, and named with an alias such as
``zip-zatoshizakamoto-42millionzec`` until the ZIP Editors have assigned
it a ZIP number (Champions MUST NOT self-assign ZIP numbers).
it a ZIP number (Owners MUST NOT self-assign ZIP numbers).
ZIP Champions are responsible for collecting community feedback on both
ZIP Owners are responsible for collecting community feedback on both
the initial idea and the ZIP before submitting it for review. However,
wherever possible, long open-ended discussions on public mailing lists
should be avoided.
@ -107,8 +107,8 @@ complete description of the proposed enhancement. The enhancement must
represent a net improvement. The proposed implementation, if applicable,
must be solid and must not complicate the protocol unduly.
The ZIP Champion may update the draft as necessary in the git
repository. Updates to drafts should also be submitted by the Champion
The ZIP Owner may update the draft as necessary in the git
repository. Updates to drafts should also be submitted by the Owner
as pull requests.
@ -116,10 +116,10 @@ Transferring ZIP Ownership
--------------------------
It occasionally becomes necessary to transfer ownership of ZIPs to a new
Champion. In general, we'd like to retain the original Champion as a
co-Champion of the transferred ZIP, but that's really up to the original
Champion. A good reason to transfer ownership is because the original
Champion no longer has the time or interest in updating it or following
Owner. In general, we'd like to retain the original Owner as a
co-Owner of the transferred ZIP, but that's really up to the original
Owner. A good reason to transfer ownership is because the original
Owner no longer has the time or interest in updating it or following
through with the ZIP process, or has fallen off the face of the 'net
(i.e. is unreachable or not responding to email). A bad reason to
transfer ownership is because you don't agree with the direction of the
@ -127,8 +127,8 @@ ZIP. We try to build consensus around a ZIP, but if that's not possible,
you can always submit a competing ZIP.
If you are interested in assuming ownership of a ZIP, send a message
asking to take over, addressed to both the original Champion and the ZIP
Editors. If the original Champion doesn't respond to email in a timely
asking to take over, addressed to both the original Owner and the ZIP
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 :).
@ -161,7 +161,7 @@ For each new ZIP that comes in an Editor confirms the following:
addressed.
* The licensing terms are acceptable for ZIPs.
If the ZIP isn't ready, the editor will send it back to the Champion for
If the ZIP isn't ready, the editor will send it back to the Owner for
revision, with specific instructions.
Once the ZIP is ready for the repository it should be submitted as a
@ -210,12 +210,12 @@ for any of the following reasons:
* it updates a Released ZIP to Draft when the specification is already
implemented and has been in common use;
* it violates any specific "MUST" or "MUST NOT" rule in this document;
* the expressed political views of a Champion of the document are inimical
* 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 Champion);
* it is not authorized by the stated ZIP Champions;
* it removes an Champion without their consent (unless the reason for removal
is directly related to a breach of the Code of Conduct by that Champion).
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).
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
@ -291,7 +291,7 @@ header fields are REQUIRED::
 ZIP:
 Title:
 Champions:
 Owners:
 Status:
 Category:
Created:
@ -306,18 +306,17 @@ The following additional header fields are OPTIONAL::
Obsoletes:
Updates:
The Champions header lists the names and email addresses of all the
champions/owners of the ZIP. The format of the Champions header value
SHOULD be::
The Owners header lists the names and email addresses of all the
Owners of the ZIP. The format of the Owners header value SHOULD be::
Random J. User <address@dom.ain>
If there are multiple champions, each should be on a separate line.
If there are multiple Owners, each should be on a separate line.
While a ZIP is in private discussions (usually during the initial Draft
phase), a Discussions-To header will indicate the mailing list or URL
where the ZIP is being discussed. No Discussions-To header is necessary
if the ZIP is being discussed privately with the Champion, or on the
if the ZIP is being discussed privately with the Owner, or on the
Zcash email mailing lists.
The Category header specifies the type of ZIP: Consensus, Standards Track,
@ -376,7 +375,7 @@ ZIP Status Field
* Draft: All initial ZIP submissions have this status.
* Withdrawn: If the Champion decides to remove the ZIP from
* Withdrawn: If the Owner decides to remove the ZIP from
consideration by the community, they may set the status to Withdrawn.
* Active: Typically only used for Process/Informational ZIPs, achieved
@ -388,7 +387,7 @@ ZIP Status Field
validate this change before it is approved.
* Rejected: The status when progress hasn't been made on the ZIP in one
year. Can revert back to Draft/Proposed if the Champion resumes work
year. Can revert back to Draft/Proposed if the Owner resumes work
or resolves issues preventing consensus.
* Implemented: When a Consensus or Standards Track ZIP has a working
@ -405,11 +404,11 @@ More details on the status workflow in the section below.
Specification
-------------
Champions of a ZIP may decide on their own to change the status between
Owners of a ZIP may decide on their own to change the status between
Draft or Withdrawn.
A ZIP may only change status from Draft (or Rejected) to Proposed, when
the Champion deems it is complete and there is rough consensus on the
the Owner deems it is complete and there is rough consensus on the
mailing list, validated by both the Electric Coin Company and Zcash Foundation
Editors. One Editor will not suffice -- there needs to be consensus
among the Editors. If it's a Standards Track ZIP, upon changing status to
@ -419,16 +418,16 @@ the specified network upgrade. (All ``Network Upgrade`` schedules will be
distributed via the Zcash Ecosystem Developer list by the Editors.)
A Standards Track ZIP may only change status from Proposed to
Implemented once the Champion provides an associated reference
Implemented once the Owner provides an associated reference
implementation, typically in the period after the network upgrade's
specification freeze but before the implementation audit. If the Champion
misses this deadline, the Editors or Champion(s) may choose to update
specification freeze but before the implementation audit. If the Owner
misses this deadline, the Editors or Owner(s) may choose to update
the ``Network Upgrade`` header to target another upgrade, at their
discretion.
ZIPs should be changed from Draft or Proposed status, to Rejected
status, upon request by any person, if they have not made progress in
one year. Such a ZIP may be changed to Draft status if the Champion
one year. Such a ZIP may be changed to Draft status if the Owner
provides revisions that meaningfully address public criticism of the
proposal, or to Proposed status if it meets the criteria required as
described in the previous paragraph.