Conversation
Defines what a QEP is, when one is required, where QEPs live, the Draft -> Accepted/Rejected/Withdrawn lifecycle, and decision by lazy consensus among Core Maintainers with an author-set deadline. As the first proposal, QEP-1 is also a worked example of the template. Process proposed and agreed in QuantEcon/meta#325 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Bootstraps the QuantEcon Enhancement Proposal (QEP) process by adding QEP-1, a process QEP that defines when QEPs are required, where they live, and how they are decided, and by adding QEP-1 to the repository’s README index.
Changes:
- Adds
qeps/qep-0001-purpose-and-process.mddefining the QEP purpose, lifecycle/statuses, decision rule, and template/format. - Updates the README index table to include QEP-1 with status
Draft.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| README.md | Adds QEP-1 to the QEP index table. |
| qeps/qep-0001-purpose-and-process.md | Introduces QEP-1 document specifying the QEP process, structure, and decision workflow. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
In favor, no objections. |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
- Use the XXXX filename placeholder, matching README, AGENTS.md, and the issue template; QEP-1 was the only file still using NNNN. - Reflect the complete-registry convention: the README index row is added when the PR opens (step 2), and on the decision its status is updated across the frontmatter, header table, and index row (step 5). - State the numbering convention explicitly: numbers are unpadded in text (QEP-1), and only the filename zero-pads to four digits. Status stays Draft; the acceptance flip happens at decision time. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Step 3: the decision deadline is recorded in the PR description (rather than a milestone), keeping it next to the discussion. - Step 4: objections are raised as PR comments; absent any sustained objection the QEP is Accepted — matching the lazy-consensus model without requiring formal review approvals. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Updated following review — all changes are pushed. Summary of what changed since the initial draft:
Status remains Draft, and will flip to Accepted in the same commit that records the decision at the deadline. For context, supporting scaffolding has landed on |
|
For context, this formalizes the QEP process discussed and agreed in QuantEcon/meta#325 — opened as a PR so we adopt the process through the process itself. Opening the comment period now under the QEP-1 rules: lazy consensus, so if there's no sustained objection by Tuesday 30 June 2026 I'll set the status to Accepted, add it to the index, and merge. QEP-1 is deliberately self-describing — it's both the process and a worked example of the template, so feedback on the shape of a QEP (sections, frontmatter, statuses) is just as welcome as feedback on the process. @jstac you already signed off on the shape in QuantEcon/meta#325 — a 👍 or any objection here closes the loop. |
|
Thanks @mmcky , I approve |
Lazy consensus reached per the QEP-1 process: @jstac approved on the PR and @mmcky approves, building on the agreement in QuantEcon/meta#325. Flip the status Draft -> Accepted in all three places kept in sync per AGENTS.md: the frontmatter, the in-document header table, and the README index row. Merging ahead of the announced 30 June 2026 window; for a small team with sign-off already in hand, the comment period adds no value here. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Closing the loop early. With @jstac's approval here and the shape already agreed in QuantEcon/meta#325, I'm merging ahead of the 30 June 2026 window I announced above — for a small team with sign-off in hand, holding it open another two weeks adds no value. Flagging it rather than merging silently, since I'd named a date. I've flipped the status Draft → Accepted in the same commit, across all three places we keep in sync (frontmatter, header table, and the README index). The Copilot |
…gent Address the PR review's must-fixes and cheap hardening. - stamp.mjs (#1): detect a merge commit and diff against the first parent (`git diff --name-only HEAD^1 HEAD`) instead of `git diff-tree -r HEAD`, which prints nothing for a merge and would make stamping silently no-op if a QEP PR is merged as a merge commit rather than squashed. Verified on synthetic merge and squash commits. - check.mjs (#2, #5): a new QEP must start unversioned (v0); a versioned QEP may not drop its version field (once versioned, stays versioned). Distinguishes a brand-new file from a v0 file via a base-existence check. - check.mjs (#3): validate that type/status are known enum values. - check.mjs (#8): tolerate a hand-typed ASCII "-" or empty README Version cell for a v0 QEP (stamp.mjs normalises it to the en dash post-merge), so the cell no longer blocks the PR with a visually identical-looking parity error. - stamp-version.yml (#6b): push explicitly with `git push origin HEAD:main`. - QEP-1 + AGENTS.md (#7): the site uses book-theme today, so make the type/version pills and git-history-dropdown claims contingent on the QuantEcon theme; lead with the always-true README columns. Describe the strengthened PR checks. All eight check.mjs scenarios pass in an isolated synthetic repo; check.mjs passes on the real tree. Stays at v1 (no normative rule changed). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
## Problem The **Deploy QEP site** workflow has failed on every push to `main` since the QEP-1 v1 merge (#5) — including the merge commit's own deploy, so the amended QEP-1 (the new `Type`/`Version` columns and pills) **never reached the live site**. The last successful deploy was #1 on 2026-06-16. The failure is unrelated to #5. `myst build --html` serves all pages fine, then fails resolving the favicon. With no favicon configured, MyST falls back to fetching the default from `https://mystmd.org/favicon.ico`. On the runner's Node 24.17.0 that remote fetch dies with `ERR_STREAM_PREMATURE_CLOSE` (a recent `http.Agent` keep-alive change), retries 3× and aborts the build: ``` Failed to fetch http://localhost:3000/favicon.ico after 3 attempts. ##[error]Process completed with exit code 1. ``` ## Fix Vendor QuantEcon's favicon into the repo and reference it locally, so the static build never reaches the network for it: ```yaml site: options: favicon: favicon.png ``` ## Verification Built locally on Node 26 with the change: | Check | Result | |---|---| | `myst build --html` exit code | `0` | | Build errors | none | | Emitted `_build/html/favicon.ico` | byte-identical to the vendored source | | `mystmd.org/favicon` references in output | none | | HTML `<head>` | `<link rel="icon" href="/favicon.ico"/>` | Once merged, the push to `main` re-triggers the deploy, which should now go green and publish the amended QEP-1. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Bootstraps the QEP process by adding QEP-1: QEP Purpose and Process — the
self-describing first proposal — plus its row in the README index.
QEP-1 codifies what was proposed and agreed in QuantEcon/meta#325:
whole team works. Everyday single-repo work never needs one.
qeps/qep-NNNN-slug.md, rendered to GitHub Pages.rejected, and withdrawn QEPs are all merged so the record is durable.
@jstac breaks ties or defers.
This PR is itself a worked example of the workflow it defines.
Decision
Per the process, please comment by Tuesday 30 June 2026. Lazy consensus: no
sustained objection by then = Accepted, at which point I'll flip the status to
Acceptedand merge. Follow-up (separate PR): re-record the label-set decision(QuantEcon/meta#324) as QEP-2.
Background and the full discussion: QuantEcon/meta#325