Deirdre Connolly (@dconnolly) is leaving the Zcash Foundation, and also resigning as a ZIP Editor. I would like to personally thank her for being an amazing and diligent colleague and editor, and wish her well for the future.
Three new ZIP Editors will take her place: Jack Grigg (@str4d) from ECC, and Teor (@teor) and Conrado Gouvea (@conradoplg) from the Zcash Foundation.
We would also like to welcome other people to apply to be ZIP Editors. Please read ZIP 0 (as modified by the PR below) for what this entails. We would also recommend joining ZIP Editor meetings — ask on this thread or by DM to me either on the forum or on Discord (@dairaemma) if you would like to be invited.
This PR appoints multiple ZIP editors, and modifies the decision-making process for multiple editors. It also improves the ZIP review process, and updates ZIP processes to reflect current practice.
Detailed Changes
ZIP Editor changes:
Adds str4d, teor, and Conrado as ZIP editors;
Removes Deirdre as a ZIP editor;
Ensures that ZIP editors declare potential or perceived conflicts of interest;
Clarifies how editors are added, removed, or resign;
Lists actions that should be taken when editors change;
List processes that should be reviewed on an ongoing basis;
Updates how ZIP editors can be contacted.
Decision-making changes:
Clarifies that ZIP editor consensus is required for significant ZIP changes;
Documents the current ZIP meeting process;
Adds a ZIP Secretary role for agendas, minutes, and posting significant decisions to the forums.
ZIP process changes:
Splits big-picture content review from detailed format review;
Clarifies that ZIP editor suggestions are individual opinions, which should be independent of employment or other relationships;
Clarifies that ZIP owners can reject suggestions;
Documents that draft ZIPs should be submitted to the forums and the git repository;
Documents that HTML updates are the responsibility of ZIP editors, not ZIP owners;
Clarifies conformance wording in a number of places and removes redundancies;
Fixes inconsistent spelling of the Obsoleted-By and Updated-By headers.
If possible I would like to attend meetings as a learning exercise. I’m unsure if I have the time to apply as an editor but I would like to watch and learn if that’s ok with the team.
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.
Add a paragraph on public transparency about influence or constraints.
Also, Aditya Bharadwaj (@aiyadt, Nighthawk developer and co-author of ZIP 317) has agreed to be the first ZIP Editor not from either ECC or ZF, so I will add that change to zcash/zips#716.
I hope to see more “lurkers” and also I’d like to see the status of “reviewers” elevated. In fact, you inspired me to file a ticket about this.
In my experience, a newcomer who’s genuinely curious and not afraid to ask basic questions of experts can often be as valuable as expert reviewers, because the more basic questions help anchor any proposal back into the big picture, the starting assumptions, etc… -and they also force experts to improve how they describe things to be simpler, which often helps improve the actual technology. After all, tech designs are just descriptions of tech, so simplifying or improving a description can often simplify or improve a design.
So I highly encourage more lurkers in ZIP editing meetings.
