QEPs are short, durable documents that record decisions affecting more than one QuantEcon repository, or that change how the team works — label conventions, editorial policy, tooling standards, licensing, and similar cross-cutting choices.
They give QuantEcon one place to find what was decided, when, and why, with a consistent shape and a clear decision rule. Everyday, single-repo work does not need a QEP.
📖 Rendered index: https://
Index¶
| QEP | Title | Type | Status | Version |
|---|---|---|---|---|
| QEP-1 | QEP Purpose and Process | process | Accepted | v3 |
| QEP-2 | Standard GitHub Label Set and Labelling Policy | standard | Accepted | – |
| QEP-3 | Repository Naming and Types | standard | Accepted | – |
QEPs that set an ongoing rule are maintained in place: a substantive amendment bumps
the QEP’s version (shown above) under the same review process, rather than superseding
the whole document — see QEP-1. The index table is generated from each QEP’s
frontmatter after merge — do not hand-edit it; version-hash is stamped at the same time.
Version shows v{N} from v0 up; a – marks a QEP the stamp has not reached yet
(see QEP-1’s Adoption).
Proposing a QEP¶
Float the idea. Open a QEP discussion issue to socialise it and confirm it needs a QEP.
Draft it. Copy
qeps/template.mdtoqeps/qep-XXXX-short-slug.md, fill it in with Status: Draft, and open a PR. The index row above is generated at merge — do not add one.Decide. A Core Maintainer other than the author approves it once it has been announced and no objection is outstanding — nobody accepts their own QEP; the QEP is merged recording the outcome (Accepted / Rejected / Withdrawn).
The process itself is defined in QEP-1.
Background¶
The QEP process was proposed and discussed in QuantEcon/meta#325.