NEP 0 — Purpose and process — NumPy Enhancement Proposals

Jarrod Millman <millman@berkeley.edu>
NEP stands for NumPy Enhancement Proposal. A NEP is a design document providing information to the NumPy community, or describing a new feature for NumPy or its processes or environment. The NEP should provide a concise technical specification of the feature and a rationale for the feature.
We intend NEPs to be the primary mechanisms for proposing major new features, for collecting community input on an issue, and for documenting the design decisions that have gone into NumPy. The NEP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the NEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal [1].
There are three kinds of NEPs:
A Standards Track NEP describes a new feature or implementation for NumPy.
An Informational NEP describes a NumPy design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational NEPs do not necessarily represent a NumPy community consensus or recommendation, so users and implementers are free to ignore Informational NEPs or follow their advice.
A Process NEP describes a process surrounding NumPy, or proposes a change to (or an event in) a process. Process NEPs are like Standards Track NEPs but apply to areas other than the NumPy language itself. They may propose an implementation, but not to NumPy’s codebase; they require community consensus. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in NumPy development. Any meta-NEP is also considered a Process NEP.
The NEP process begins with a new idea for NumPy. It is highly recommended that a single NEP contain a single key proposal or new idea. Small enhancements or patches often don’t need a NEP and can be injected into the NumPy development workflow with a pull request to the NumPy repo. The more focused the NEP, the more successful it tends to be. If in doubt, split your NEP into several well-focused ones.
Each NEP must have a champion—someone who writes the NEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The NEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is suitable for a NEP. Posting to the numpy-discussion mailing list is the best way to go about doing this.
The proposal should be submitted as a draft NEP via a GitHub pull request to the doc/neps directory with the name nep-<n>.rst where <n> is an appropriately assigned four-digit number (e.g., nep-0000.rst). The draft must use the NEP X — Template and instructions file.
Once the PR for the NEP is in place, a post should be made to the mailing list containing the sections up to “Backward compatibility”, with the purpose of limiting discussion there to usage and impact. Discussion on the pull request will have a broader scope, also including details of implementation.
At the earliest convenience, the PR should be merged (regardless of whether it is accepted during discussion). Additional PRs may be made by the Author to update or expand the NEP, or by maintainers to set its status, discussion URL, etc.
Standards Track NEPs consist of two parts, a design document and a reference implementation. It is generally recommended that at least a prototype implementation be co-developed with the NEP, as ideas that sound good in principle sometimes turn out to be impractical when subjected to the test of implementation. Often it makes sense for the prototype implementation to be made available as PR to the NumPy repo (making sure to appropriately mark the PR as a WIP).
NEPs are discussed on the mailing list. The possible paths of the status of NEPs are as follows:
All NEPs should be created with the Draft status.
Eventually, after discussion, there may be a consensus that the NEP should be accepted – see the next section for details. At this point the status becomes Accepted.
Once a NEP has been Accepted, the reference implementation must be completed. When the reference implementation is complete and incorporated into the main source code repository, the status will be changed to Final.
To allow gathering of additional design and interface feedback before committing to long term stability for a language feature or standard library API, a NEP 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, but additional user feedback is needed before the full design can be considered “Final”. Unlike regular accepted NEPs, provisionally accepted NEPs may still be Rejected or Withdrawn even after the related changes have been included in a Python release.
Wherever possible, it is considered preferable to reduce the scope of a proposal to avoid the need to rely on the “Provisional” status (e.g. by deferring some features to later NEPs), as this status can lead to version compatibility challenges in the wider NumPy ecosystem.
A NEP can also be assigned status Deferred. The NEP author or a core developer can assign the NEP this status when no progress is being made on the NEP.
A NEP can also be Rejected. Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. The Withdrawn status is similar—it means that the NEP author themselves has decided that the NEP is actually a bad idea, or has accepted that a competing proposal is a better alternative.
When a NEP is Accepted, Rejected, or Withdrawn, the NEP should be updated accordingly. In addition to updating the status field, at the very least the Resolution header should be added with a link to the relevant thread in the mailing list archives.
NEPs can also be Superseded by a different NEP, rendering the o