diff --git a/active/ZEP0000.md b/active/ZEP0000.md index a231664..f6acf50 100644 --- a/active/ZEP0000.md +++ b/active/ZEP0000.md @@ -12,7 +12,7 @@ nav_order: 1 # ZEP 0 — Purpose and process -Author: Sanket Verma [(@MSanKeys963)](https://github.com/msankeys963), Zarr +Author: Sanket Verma [(@msankeys963)](https://github.com/msankeys963), Zarr Email address: @@ -20,9 +20,13 @@ Status: Active Type: Process -Created: 2022-14-03 +Created: 2022-03-14 -Discussion: +Discussion #1: + +Revised on: 2024-10-15 + +Discussion #2: ## What is ZEP? @@ -48,6 +52,8 @@ community using the project in any way. ## ZEP audience + + The typical primary audience for ZEPs is the developers working on Zarr and its various implementations, the Zarr steering council as well as the Zarr community. @@ -58,31 +64,25 @@ that require collaboration across multiple projects. ## ZEP types -- **Specification ZEP** - -Specification ZEPs deal with the changes related to [Zarr Specifications]. -The SPEC ZEP (abbreviation of Specification ZEP) for now introduces changes in -the core specification of Zarr. The changes related to core specification follow a -strict and thorough review process and should be adopted by everyone in the -Zarr community. +- **Core ZEP** -- **Core protocol ZEP** + Describes a ZEP which involves changes in the core specification of Zarr. Core -protocol ZEPs (commonly known as Core ZEPs) are a part of SPEC ZEPs and apply -to [Zarr Specifications] and its various implementations under the -[zarr-developers/zarr_implementations] GitHub repo. The core protocol ZEPs -should be adopted by every implementation of Zarr and, in general, the overall -Zarr community. Core ZEPs must go through a thorough review process, including -involvement, discussion, and voting from the author of the proposed ZEP, Zarr -Steering Council, author(s) of various Zarr implementations (ZIC), and -open-source projects/research groups using Zarr and the general Zarr community. -The general advice is that everyone should be made aware of changes introduced -by core ZEPs. Core protocol ZEPs require community consensus, and developers or -users are typically not free to ignore them. - -Note: Currently, Specification ZEPs only deal with the core specification of Zarr. -The scope of SPEC ZEPs will be extended in the future. +ZEPs apply to [Zarr Specifications] and its various implementations under the +[zarr.dev/implementations]. The core ZEPs should be adopted by every +implementation of Zarr and, in general, the overall Zarr community. Core ZEPs +must go through a thorough review process, including involvement, discussion, +and voting from the author of the proposed ZEP, Zarr Steering Council, author +(s) of various Zarr implementations (ZIC), and open-source projects/research +groups using Zarr and the general Zarr community. The general advice is that +everyone should be made aware of changes introduced by core ZEPs. Core ZEPs +require community consensus, and developers or users are typically not free to +ignore them. + +Since core ZEPs are reviewed, adopted and implemented by the majority of the Zarr community — every accepted and approved one will result in a major version increment of the Zarr specification. + + - **Informational ZEP** @@ -107,9 +107,9 @@ is also considered a Process ZEP. The ZEP process begins with a new idea for Zarr. It is highly recommended that a single ZEP contain a single key proposal or new idea. Small enhancements or patches often don’t need a ZEP and can be injected into the Zarr development -workflow with a pull request to the [ZEPs] or [zarr-specs] repo. The more -focused the ZEP, the more successful it tends to be. If in doubt, split your -ZEP into several well-focused ones. +workflow with a pull request to the [zarr-specs] repo. The more focused the +ZEP, the more successful it tends to be. If in doubt, split your ZEP into +several well-focused ones. Each ZEP must have a champion -- someone who writes the ZEP using the style and format described below, shepherds the discussions in the appropriate forums, @@ -117,9 +117,8 @@ and attempts to build community consensus around the idea. The ZEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is suitable for a ZEP. -**Asking around during the [ZEPs meetings]/creating an issue in the -[ZEPs] repository/posting to [Gitter]/posting on the organization [discussions] -are the best ways to do this.** +**Creating an issue in the [zarr-specs] repository, asking around during the +[ZEPs meetings], and posting to [Zulip] are the best ways to do this.** The ZEP champion is the lead author of the ZEP. A ZEP should have a lead author and can have multiple co-author(s). @@ -137,32 +136,34 @@ mentioned below. This allows the author to flesh out the draft ZEP to make it properly formatted, of high quality, and address initial concerns about the proposal. -Spec ZEPs consist of two parts, a PR to the [zarr-specs] repository containing -changes to the spec and a PR to the [ZEPs] repository containing a narrative -document explaining the need, importance and use-case for the change. It is -also highly recommended that the specification ZEP be accompanied by an -implementation PR in at least one of the repositories represented in the -[zarr-developers/zarr_implementations]. - ## Submitting a ZEP -For SPEC ZEPs, the proposal should be submitted as a draft ZEP via two GitHub -pull requests, one to the [ZEPs] repo and the other to the [zarr-specs] repository. +### For Core ZEPs -The first PR should contain the narrative text of the ZEP and should be -submitted in the zep repository with the name `zep-.md` under [/zeps/draft/] -where `` is an appropriately assigned four-digit number. The draft ZEP must -use the [ZEP X - Template and Instructions][template.md] file. +The proposal should be submitted as a draft ZEP via a GitHub pull +request to the [zarr-specs] repository. -The second PR should contain actual changes and should be submitted in the -[zarr-specs] repository. The PR should mention the assigned four-digit ZEP -number from the [zarr-developers/zeps] repository. +The PR should contain the narrative document explaining the need, importance, +and use case for the change of the ZEP and should be submitted in the +zarr-specs repository with the name `zep-: .md` under +[/zarr-specs/docs/zeps/draft], where `<n>` is an appropriately assigned +four-digit number. The draft ZEP must use the [ZEP X - Template and +Instructions][template.md] file. -For ZEPs other than SPEC, the proposal should be submitted as a draft ZEP via a -GitHub pull request to the [zarr-developers/zeps] repository with the name -`zep-<n>.md` where `<n>` is an appropriately assigned four-digit number (e.g., -zep-0000.md). The draft ZEP must use the -[ZEP X - Template and Instructions][template.md] file. +The Core ZEPs PR should also contain actual changes to the specification under +[/zarr-specs/docs/specs/...] and mention the assigned four-digit ZEP number +from the ZEP document. + +It is also highly recommended that the PR should accompany a complete +implementation or at least an implementation PR in one of the repositories +represented at [zarr.dev/implementations]. + +### For Informational and Process ZEPs + +The proposal should be submitted as a draft ZEP via a GitHub pull request to +the [zarr-specs] repository with the name `zep-<n>: <title>.md` where `<n>` is +an appropriately assigned four-digit number (e.g., zep-0000.md). The draft ZEP +must use the [ZEP X - Template and Instructions][template.md] file. A few points to consider while submitting your ZEP: @@ -170,25 +171,25 @@ A few points to consider while submitting your ZEP: - The title should accurately describe the content. - The ZEP’s language (spelling, grammar, sentence structure etc.) and code style should be correct and conformant. +<!-- Mention Zarr-Spec devs in line: 176-180, after zarr-developers/governance/#44 is finalised --> + The [Zarr Steering Council] and the [Zarr Implementations Council] will not unreasonably deny publication of a ZEP. Reasons for denying ZEP include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not taking care of Zarr [CODE OF CONDUCT]. -→ **In conclusion: The submission of SPEC ZEPs needs two PRs, and other ZEPs need one PR.** - ## Discussing a ZEP -As soon as the draft ZEP is committed to the ZEP repository, the author -(s) should create a discussion thread for the ZEP to provide a central place to -discuss and review its contents. The ZEP author(s) may create an issue in -[ZEPs] repository for informational and process ZEPs and or similarly create an -issue in [zarr-specs] repository for specifications ZEPs. +As soon as the draft ZEP is committed to the [zarr-specs] repository, the author +(s) should use the submitted PR for the ZEP as a central place to discuss and +review its contents. The ZEP author(s) may create additional issues in the +[zarr-specs] repository if the discussion gets long, complicated and hard to +follow in the submitted PR. The separate issue(s) may provide a place for +focused discussion on various portions of the draft ZEP. -If the author prefers to hold the discussion for SPEC ZEPs in the second PR -submitted in the [zarr-specs] repository (as mentioned above), there's no need -to create an issue. +In all cases, the author(s) should add the link of the additional issues created +to the PR description and the `Discussion` section of the ZEP. The discussion regarding the ZEP should follow Zarr’s [CODE OF CONDUCT] at all times. @@ -200,32 +201,23 @@ phase, collaborating with other community members with expertise in the ZEP’s subject matter, and picking appropriately-specialised discussion for the ZEP’s topic should be considered. ZEP authors should use their discretion here. -Once the ZEP is committed to the ZEP repository, substantive issues should -generally be discussed on the canonical public thread, as opposed to private +Once the ZEP PR is committed to the [zarr-specs] repository, substantive issues +should generally be discussed on the canonical public thread instead of private channels or unrelated venues. This ensures everyone can follow and contribute, -avoids fragmenting the discussion, and makes sure it is fully considered as -part of the ZEP review process. Comments, support, concerns and other feedback -on this designated thread are a critical part when reviewing the ZEP. +avoids fragmenting the discussion, and ensures it is entirely considered part +of the ZEP review process. Comments, support, concerns, and feedback on this +designated thread are critical when reviewing the ZEP. ## Review and Resolution The possible paths of the status of ZEPs are as follows: -![Flowchart](../assets/images/flowchart.png) +![Flowchart](../assets/images/zep_flowchart.png) All ZEPs should be created with the `Draft` status. Eventually, after the discussion, there may be a consensus that the ZEP should -be accepted - see the next section for details. At this point, the status -becomes `Accepted`. - -**Once a Specification ZEP has been Accepted**, the second PR which was submitted in -the [zarr-specs] repository must be merged. After that, the status will be -changed to `Final`. - -**Once an informational or process ZEP has been Accepted**, the author should -implement changes in the procedure, guidelines, decision-making process, etc. -ASAP. +be accepted. At this point, the status becomes `Accepted`. To allow the gathering of additional design and interface feedback before committing to long term stability for specification change or standard library @@ -233,7 +225,7 @@ API, ZEP may also be marked as `“Provisional”`. This is short for “Provisionally Accepted” and indicates that the proposal has been accepted for inclusion in the reference implementation or storage specification, but additional user feedback is needed before the full design can be considered -“Final”. Unlike regular accepted ZEPs, provisionally accepted ZEPs may still be +`“Final”`. Unlike regular accepted ZEPs, provisionally accepted ZEPs may still be Rejected or Withdrawn even after the related changes have been included in a Zarr release. @@ -242,6 +234,8 @@ proposal to avoid the need to rely on the `“Provisional”` status (e.g. by deferring some features to later ZEPs), as this status can lead to version compatibility challenges in the wider Zarr ecosystem. +<!-- Mention Zarr-Spec devs in line: 239-241, after zarr-developers/governance/#44 is finalised --> + A ZEP can also be assigned status `Deferred`. The ZEP author or [Zarr Steering Council] or Zarr Implementations Council can assign the ZEP this status when no progress is being made on the ZEP. @@ -264,107 +258,197 @@ original and new ZEPs respectively. Process ZEPs may also have a status of ## How does a ZEP become accepted? -A ZEP is `Accepted` by the consensus of all interested contributors. We need a -concrete way to tell whether the agreement has been reached. - -→ **For Core ZEPs** - -We believe Core ZEPs are of utmost importance and should follow a thorough -review before acceptance. Core ZEPs introduce changes in the core -specification, which are necessary for every other implementation and everyone -in the general community to follow. The [Zarr Steering Council] (ZSC) and -[Zarr Implementations Council] (ZIC) closely review the Core ZEPs, while the -author(s) should simultaneously engage the community in their ZEP at several -discussion forums mentioned previously. The ZSC and ZIC would take community -consensus into account while taking the final decision on the Core ZEPs. Author -(s) should ensure that the involvement and discussion form the consensus on the -ZEP from the author of various Zarr implementations, open-source -projects/research groups using Zarr, the general Zarr community, and anyone -else they, ZSC and ZIC think should be included in the discussions. The Core -ZEPs are accepted by: - -- Unanimous approval of the [Zarr Steering Council] - -- Majority approval of the [Zarr Implementations Council] - -> *Approval indicates that implementation plans to implement the new spec -> features. Not all implementations must implement all features, but a majority is -> required.* - -- No vetos from the [Zarr Implementations Council] +<!-- Mention Zarr-Spec devs in line: 263-267, after zarr-developers/governance/#44 is finalised --> -> *Each implementation has the right to veto a ZEP if it would cause severe -> problems for that implementation.* +The Zarr Enhancement Proposal (ZEP) undergoes a systematic process to ensure its +successful adoption by software implementations governed by the Zarr +Implementation Council (ZIC). This process guarantees the stability of the +specification, fosters community consensus, and maintains a high standard of +agreement among maintainers. -Read more about [Zarr Implementations Council]. +### Reading Phase +The Reading Phase, or Request for Comments (RFC) phase, initiates the ZEP +proposal process, marking the introduction of the proposal to the Zarr +community. -→ **For other ZEPs** - -For ZEPs, other than specifications, the author(s) must form a consensus around -their proposal. They may refer to [Discussing a ZEP]( #discussing-a-zep ) section to pick an avenue -for discussion and engaging the community. - -**When you think ZEP is ready to accept**, create a new issue in [zarr-developers/zeps] -with a subject like: - -> `Proposal to accept ZEP <number>: <title>` +1. **Stakeholder Engagement**: + - During this phase, stakeholders actively participate by expressing + concerns and opinions related to the proposal. + - The author uses the submitted PR or establishes a separate GitHub issue to + facilitate discussions, addressing questions, doubts, and concerns. -**In the body of your discussion**, you should: +2. **Duration Definition**: + - The author communicates the duration of the Reading Phase when submitting + the ZEP, typically ranging from a suggested 3-4 weeks with flexibility + for exceptional circumstances. + +3. **Feedback Collection**: + - Authors anticipate and welcome suggestions from readers to enhance the + proposal, encouraging general comments to refine definitions, add URLs, + or improve overall readability. + +4. **ZIC Acknowledgment**: + - ZIC members publicly acknowledge their engagement during the Reading + Phase, ensuring a comprehensive understanding of community involvement. + +<!-- Mention Zarr-Spec devs in line: 297-300, after zarr-developers/governance/#44 is finalised --> + +5. **VETO Mechanism**: + - A VETO option is available to ZIC members if the proposal introduces + potential breaking changes to existing software implementations, serving + as a precautionary measure. + +Authors may utilize the submitted pull request (PR) for gathering comments, +feedback, acknowledgment, and facilitating engagement from ZIC members during +the Reading Phase. + +### Implementation Phase + +The Implementation Phase encompasses the timeline during which interested +adopters actively work on integrating the proposal into their +codebases. + +1. **Declaration of Intent**: + - Before committing to implementation, ZIC members declare their intention + to adopt the proposal, contributing to the formation of a cohesive + adopter quorum; requiring the participation of a minimum of two ZIC members. -- Link to the latest version of ZEP, -- Briefly describe any major points of contention and how they were resolved, -- Include a sentence like: **“If there are no substantive objections within 7 days - from this post, then the ZEP will be accepted**; +2. **Reference Implementation**: + - The author provides a reference implementation upon ZEP submission, a + crucial resource during the implementation phase. + - The inclusion of an Implementation Notes section in the ZEP proposal + further assists ZIC members in understanding the implementation nuances. + +3. **Collaborative Iteration**: + - Implementors are expected to actively engage by raising issues, providing + constructive suggestions, and highlighting areas for improvement in the + ZEP proposal. -After you create the issue, you should make sure to link the newly created -thread in the `Discussion` section of the ZEP, so that people can find it later. +4. **Feature Completion Table**: + - For proposals with divisible implementation details, maintaining a + real-time Feature Completion Table ensures effective coordination among + the Zarr community and stakeholders. -Generally, the ZEP author will be the one to create this post, but anyone can -do it – the important thing is to make sure that everyone knows when a ZEP is -on the verge of acceptance, and give them a final chance to respond. If -there’s some special reason to extend this final comment period beyond -`7 days`, then that’s fine, just say so in the post. You shouldn’t do less -than `7 days`, because sometimes people are travelling or similar and need -some time to respond. +<!-- Mention Zarr-Spec devs in line: 335-343, after zarr-developers/governance/#44 is finalised --> -There may be a case that a ZEP didn’t attract needed attention towards it, the -engagement from the community is low, and `7 days` pass by. In this case, -the author(s) of the ZEP must make necessary efforts to spread the word about -the ZEP through [Gitter] or using the organisation [discussions] feature of -GitHub or, if needed, creating an additional issue in the [community] or [ZEPs] -repository. In addition, the author(s) should get in touch with the -[Zarr Steering Council] to prevent the case that the ZEP was accepted due to -less participation from the community. +5. **Veto Consideration**: -If all the above options are exhausted by the author(s), then it’s the -responsibility of the [Zarr Steering Council] to take the final decision on the -ZEP. + - ZIC members hold the authority to veto the proposal if they identify + potential issues with its implementation in their software environments. + A veto signals the need to resolve these concerns before proceeding, + indicating that the ZEP proposal may not advance further until the + underlying issues are clarified. + - Should the author encounter challenges in addressing the vetoed concerns, + the ZEP proposal may be subject to rejection at this stage. + +5. **Concluding Implementation Phase**: + + - Upon the completion of a majority of implementations within the + established quorum and the absence of any vetoes, the ZEP may be + designated as `Accepted` or `Provisional` following consensus among ZIC + members and the broader Zarr community. + +These designations signify the successful integration and adoption of the +proposal into the Zarr ecosystem, reflecting its alignment with existing +implementations and consensus-driven acceptance. + +The author may utilize the submitted pull request (PR) or create an additional +issue in the zarr-specs repository to gather implementation notes from the +established quorum. + +### Voting Phase + +<!-- Mention Zarr-Spec devs in line: 364-369, after zarr-developers/governance/#44 is finalised — who'll participate in the voting process? --> + +The Voting Phase represents the final stage where the ZIC and Zarr Steering +Council (ZSC) formally vote on the ZEP proposal. + +1. **Notification**: + - ZIC and ZSC members receive formal notification of the initiation of the Voting Phase. + +2. **Casting Votes**: + - During the vote, ZIC and ZSC members cast their votes as `YES`, `ENDORSE`, + `ABSTAIN`, or `VETO` providing clarity on their stance. + +3. **Vote Definitions**: + - `YES` indicates the member has implemented the ZEP and has no objection to + the proposal. + - `ENDORSE` signifies a commitment to future implementation, with no + objections to the proposal. + - `ABSTAIN` indicates a member's decision not to implement the ZEP but + expresses no objection to its proposal. + - `VETO` Allows a member to exercise veto power if they think the proposal + still introduces potential breaking changes to existing software + implementations, serving as a precautionary measure. + +4. **Outcome Determination**: + - In the event of a VETO, the proposal undergoes further discussion and + potential revisions to address concerns raised before proceeding. + - If the author and stakeholders are not able to resolve the concerns + regarding the proposal, the ZEP may be rejected due to lack of sufficient + support or consensus. + +5. **Majority Approval**: + - If the proposal receives a majority of `YES` and `ENDORSE` votes and no + vetoes, it proceeds to the finalization stage. + +6. **Finalization**: + - The Voting Phase concludes upon achieving a majority of approval from + voting members and resolving any pending comments or feedback. + - After this phase, the ZEP proposal attains a `Final` status, and no + further changes are permitted, ensuring a stable and conclusive outcome. -In general, the goal is to make sure that the community has consensus, not -provide a rigid policy for people to try to game. When in doubt, err on the -side of asking for more feedback and looking for opportunities to compromise. +The author may utilize the submitted pull request (PR) or create an additional +issue in the zarr-specs repository to facilitate the voting phase. + +Here's a flowchart for enhanced visual understanding of the different phases: + +![Phases](../assets/images/zep_phases.png) + +These phases are integral for ZEPs entailing substantial specification changes, +such as the incrementation of major versions (e.g., V3 → V4) or addition of new +extensions. + +Authors are also encouraged to adapt or incorporate elements of these phases for +use in Informational and Process ZEPs, as deemed appropriate. + +**Upon reaching Final status**, the corresponding pull request for the Core ZEP + in the [zarr-specs] repository must be merged. + +**Similarly, for finalised Informational or Process ZEPs**, the associated pull +request in the [zarr-specs] repository must be merged. Following this, authors +should promptly enact any procedural, guideline, or decision-making process +changes as necessary. + +Upon finalizing a ZEP, the author is responsible for: -If the final comment period passes without any substantive objections, then the -ZEP can officially be marked `Accepted`. You should create a follow-up -issue in [zarr-developers/zeps] repository notifying everyone -(celebratory emoji optional but encouraged 🎉✨), and then update the ZEP by -setting its `:Status:` to `Accepted`, and it's `:Resolution:` header to a link -to your follow-up discussion (the last issue created) thread. +- Updating the status from `Draft` to `Accepted`/`Final` and including the link for + the voting issue if applicable. +- Adding the date of acceptance in the ZEP header. +- Relocating the ZEP from [/zarr-specs/docs/zeps/draft] to + [/zarr-specs/docs/zeps/accepted or final]. +- Removing the `DRAFT` watermark from the background if present. -If there are substantive objections, then the ZEP remains in `Draft` state, -discussion continues as normal, and it can be proposed for acceptance again -later once the objections are resolved. +<!-- Mention Zarr-Spec devs in line: 435-442, after zarr-developers/governance/#44 is finalised --> -In unusual cases, the [Zarr Steering Council] may be asked to decide whether a -controversial ZEP is `Accepted`. +The [Zarr Steering Council] (ZSC) and [Zarr Implementations Council](ZIC) closely +review the submitted ZEPs, while the author(s) should simultaneously engage the +community in their ZEP discussion. The ZSC and ZIC will consider community +consensus when making the final decision on ZEPs. Author(s) should ensure that +the involvement and discussion form the consensus on the ZEP from the author of +various Zarr implementations, open-source projects/research groups using Zarr, +the general Zarr community, and anyone else they think should be included in +the discussions. ## Maintenance -In general, SPEC ZEPs are no longer modified after they have reached the Final -state. The changes made to the Zarr’s core specification in the -[zarr-specs] repository are considered the ultimate reference. However, -finalised SPEC ZEPS may be updated with minor changes as needed. +In general, ZEPs are no longer modified after they have reached the `Final` +state. The changes made to the Zarr’s specification in the +[zarr-specs] repository are considered the ultimate reference. + +However, finalised ZEPs may undergo minor updates as necessary, with adherence +to semantic versioning principles. Process ZEPs may be updated over time to reflect changes to development practices and other details. The precise process followed in these cases will @@ -372,22 +456,21 @@ depend on the nature and purpose of the ZEP being updated. ## ZEP Format -ZEPs are UTF-8 encoded text files using the [GitHub flavoured markdown] format. +ZEPs are UTF-8 encoded text files using the [reStructuredText] format. Please see the [ZEP X - Template and Instructions][template.md] file and the -[GitHub Markdown Spec] for more information. +[reStructuredTextPrimer] for more information. ## Header Preamble ``` Author: <list of authors’ real names and email addresses> Status: < Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded > -Type: <Specification | Process | Informational> -Created: <date created on, in dd-mmm-yyyy format> +Type: <Core | Process | Informational> +Created: <date created on, in yyyy-mm-dd format> Require: <Previous ZEP number> -Zarr-Version: <version number> Replaces: <ZEP number> Replaced-By: <ZEP number> -Resolution: <Link to discussion thread> +Discussion: <Link to discussion thread> ``` The Author header lists the names and the email addresses of all the authors of @@ -399,7 +482,9 @@ Random J. User <address@dom.ain> ## Discussion -[https://github.com/zarr-developers/governance/pull/16] +#1: <https://github.com/zarr-developers/governance/pull/16> + +#2: <https://github.com/zarr-developers/zeps/pull/59> ## Copyright @@ -407,10 +492,10 @@ This document has been placed in the public domain. <!-- External links --> -[Gitter]: https://gitter.im/zarr-developers/community +[Zulip]: https://ossci.zulipchat.com/ [Zarr Specifications]: https://zarr-specs.readthedocs.io/ -[GitHub flavoured markdown]: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax -[GitHub Markdown Spec]: https://github.github.com/gfm/ +[reStructuredText]: http://docutils.sourceforge.net/rst.html +[reStructuredTextPrimer]: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html [template.md]: https://zarr.dev/zeps/template/template.html [ZEPs meetings]: https://zarr.dev/zeps/meetings/ @@ -422,9 +507,9 @@ This document has been placed in the public domain. <!-- github links: capitalization matches that of the repo --> [community]: https://github.com/zarr-developers/community [discussions]: https://github.com/orgs/zarr-developers/discussions +[zarr.dev/implementations]: https://zarr.dev/implementations [zarr-developers/zarr_implementations]: https://github.com/zarr-developers/zarr_implementations [zarr-specs]: https://github.com/zarr-developers/zarr-specs [ZEPs]: https://github.com/zarr-developers/zeps -[https://github.com/zarr-developers/governance/pull/16]: https://github.com/zarr-developers/governance/pull/16 [zarr-developers/zeps]: https://github.com/zarr-developers/zeps [/zeps/draft/]: https://github.com/zarr-developers/zeps/tree/main/draft \ No newline at end of file diff --git a/assets/images/zep_flowchart.png b/assets/images/zep_flowchart.png new file mode 100644 index 0000000..7381e64 Binary files /dev/null and b/assets/images/zep_flowchart.png differ diff --git a/assets/images/zep_phases.png b/assets/images/zep_phases.png new file mode 100644 index 0000000..add3f27 Binary files /dev/null and b/assets/images/zep_phases.png differ diff --git a/template/template.md b/template/template.md index 13edce4..682f80a 100644 --- a/template/template.md +++ b/template/template.md @@ -15,13 +15,11 @@ Author: <list of authors’ real name and email addresses> Status: < Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded > -Type: <Specification | Informational | Process> +Type: <Core | Informational | Process> -Created: <date created on, in dd-mmm-yyyy format> +Created: <date created on, in yyyy-mm-dd format> Discussion: <url> (link to zarr-developers post for discussion) - -Resolution: <url> (required for Accepted | Rejected | Withdrawn) ``` ## Abstract