From f61e720c02ccfe8a79a38fc8406b765a39c5fb3f Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 20 Mar 2019 03:02:47 +0000 Subject: [PATCH] s/Champion/Owner/g Co-authored-by: Josh Cincinnati --- zip-0000.rst | 79 ++++++++++++++++++++++++++-------------------------- 1 file changed, 39 insertions(+), 40 deletions(-) diff --git a/zip-0000.rst b/zip-0000.rst index 96f948ec..37e61b0e 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -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 `__. 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 `__. -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 `__ 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  -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.