Process: the decision deadline is unenforced — four open QEPs, none decidable
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 1
- Forks
- 0
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 7
Description
Summary
QEP-1 makes the decision deadline the trigger for the whole decision mechanism: step 3 requires the author to record it in the PR description, and step 4 says the Core Maintainers decide at the deadline by lazy consensus. Nothing enforces it, and as of 2026-09-08 none of the four open QEP PRs is decidable. This proposes enforcing a rule QEP-1 already has, plus three smaller repairs to the machinery around it.
Motivation
| PR | Opened | Deadline recorded | State on 2026-09-08 |
|---|---|---|---|
| #8 — QEP-4 Automation Registry | 2026-07-23 (47 days) | "To be set by the author once the draft has had a round of review" | never set |
| #13 — QEP-5 Code of AI Use | 2026-08-14 (25 days) | 2026-08-28 | 11 days past; no activity since it was opened |
| #18 — QEP-6 Project Trackers | 2026-08-26 | none — deferred to late September, deliberately | unset by design |
| #23 — QEP-1 v3 | 2026-08-27 | 2026-09-03 | 5 days past |
The last row is the sharpest: #23 is the amendment that shortens the default window to one week on the grounds that "the team is small enough that a fortnight is drift, not diligence", and it has drifted past its own deadline.
.github/scripts/check.mjs enforces version legality, the type and status enums, the README index row and its Type/Status/Version parity, and related: ↔ Related header-row consistency. It never reads the PR body. So the one field the decision depends on is required by the document and checked by nothing — which makes the process look enforced when it is not.
Two of those four rows have a cost attached that is already visible. #8 holds QEP-2's amendments (#9), so QEP-2 cannot reach v1 until QEP-4 decides — and QEP-4 has no date on which it will. #13 is policy rather than infrastructure and binds on acceptance with nothing to build, so it is the cheapest decision in the set and the most overdue.
Why does this need a QEP?
Changes how the whole team works (workflow, policy, conventions) — it amends QEP-1, presumably as v4 after #23 lands.
Proposed change
1. Enforce the deadline, or drop it. Either add a check that fails a non-draft QEP PR whose body carries no parseable decision deadline, or delete the requirement from QEP-1 and say decisions happen when the lead calls them. My preference is the check — roughly ten lines against the PR body in the existing qep-checks workflow, and it converts four stalled PRs into four dated decisions. A required field nobody supplies and nothing checks is worse than either alternative. Note the check must tolerate the deliberate case: #18's window is intentionally deferred pending evidence, so "deferred: <reason>" should satisfy it as explicitly as a date does.
2. Generate the README index from frontmatter in the post-merge stamp step. The index is a structural conflict magnet: four open QEP PRs contend for rows in one table, #18's mergeable_state is already dirty on one line from QEP-3's merge, and because check.mjs:82-85 requires the row, resolving in the merged version's favour fails CI. stamp-version.yml already syncs the Type and Version columns, so this is an extension rather than new machinery — and it retires the parity check's reason to exist.
3. Settle number allocation. QEP-1 says numbers are proposed at PR time and "confirmed (and adjusted if two proposals collide) at merge", but in practice they are treated as reserved — #24 reached for QEP-7 because 4, 5 and 6 are held by drafts, two of them open for weeks, and the published index reads 1, 2, 3. Either make the reservation explicit or assign only at merge. Free today; costs a rename the first time two drafts collide.
4. Cite sections by name, not number, stated in AGENTS.md — and add a check that ordered-list numbering is monotonic in source. Both come from live defects on #18: inserting §2 renumbered §2–§7 to §3–§8 and forced a correction onto the #24 ruling, and QEP-6's Adoption clauses are numbered 1., 2., 2., 3., 4. in source, so because Markdown renumbers on render every external "clause N" citation after the first is off by one. External consumers cite these — the qe skills, the projects dashboard's C2 contract, and three status-projects issues.
What this deliberately does not propose. No new roles, stages or ceremony. QEP-1's Roles section is deliberate — "the process is intended to stay as light as the decisions it records" — and the observed failure is not too little process but a required field with no enforcement.
Not a duplicate of
- #14 (field testing in Draft) — that is the practice between Draft and Decide; this is the deadline that ends it. They compose: #14's point 2 already asks whether a field-test amendment resets the window, which presumes a window exists.
- #22 and #23 — those settle
version/version-hashstamping from v0. No overlap with the deadline, index, numbering or citation items. - #9 — the downstream-amendment convention. Named above only as a consequence of #8 having no deadline.
Evidence is in docs/reviews/2026-09-08-cross-project-dependencies.md §7 and §10 in QuantEcon/status-projects (private).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with .github/scripts/check.mjs and the existing qep-checks workflow to understand current PR-body and metadata validation. Then inspect stamp-version.yml and AGENTS.md, along with the README index and QEP-1 conventions. Done means the team has an agreed implementation for deadline or deferred validation, index generation, number allocation, and citation or numbering checks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, javascript, markdown
- Domain
- ci-cd, documentation, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100