ZEP — Template and Instructions 

Author: <list of authors’ real name and email addresses>

Status: < Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded >

Type: <Specification | Informational | Process>

Created: <date created on, in dd-mmm-yyyy format>

Discussion: <url> (link to zarr-developers post for discussion)

Resolution: <url> (required for Accepted | Rejected | Withdrawn)

Abstract

The abstract should be a short description of what the ZEP will achieve.

Motivation and Scope

This section describes the need for the proposed change. It should describe the existing problem, who it affects, what it is trying to solve, and why. This section should explicitly address the scope of and key requirements for the proposed change.

Usage and Impact

This section describes how users of Zarr will use the new features, spec changes or a new process described in this ZEP. It should be comprised mainly of code examples that wouldn’t be possible without acceptance and implementation of this ZEP, as well as the impact the proposed changes would have on the ecosystem. This section should be written from the perspective of the users of Zarr, and the benefit it will provide them; as such, it should include implementation details only if necessary to explain the functionality.

Backward Compatibility

This section describes how the ZEP breaks backward compatibility.

Its purpose is to provide a high-level summary to users who are not interested in detailed technical discussion, but may have opinions around, e.g., usage and impact.

Detailed description

This section should provide a detailed description of the proposed change. It should include examples of how the new functionality would be used, intended use-cases and pseudo-code illustrating its use.

This section should list relevant and/or similar technologies, possibly in other libraries. It does not need to be comprehensive, just list the major examples of prior and relevant art.

Implementation

This section lists the major steps required to implement the ZEP. Where possible, it should be noted where one step is dependent on another, and which steps may be optionally omitted. Where it makes sense, each step should include a link to related pull requests as the implementation progresses.

Any pull requests or development branches containing work on this ZEP be linked to from here. (A ZEP does not need to be implemented in a single pull request if it makes sense to implement it in discrete phases).

Alternatives

If there were any alternative solutions to solving the same problem, they should be discussed here, along with a justification for the chosen approach.

Discussion

This section should have links related to any discussion regarding the ZEP. It could be GitHub issues and/or discussions. (The links to discussions in past if any, goes in this section.)

References and Footnotes

Each ZEP must either be explicitly labelled as placed in the public domain (see this ZEP as an example) or licensed under the Open Publication License.

This document has been placed in the public domain.