QEP-3 is merged to main as Draft — a state the lifecycle does not admit, and #25 waits on it

[quantecon-services]

Summary

QEP-3 is merged to main carrying status: Draft, with no open PR — a state QEP-1's lifecycle table does not admit. It has been in that state since 2026-07-10, and #25 is already waiting on its acceptance.

Motivation

QEP-1's lifecycle table defines Draft as "Under discussion on an open PR." It also states that "Accepted, Rejected, and Withdrawn QEPs are all merged, so the record is durable; only abandoned or spam drafts are closed without merging." QEP-3 is neither: it is merged (d5490fe, "QEP-3: Repository Naming and Types (#7)") and its frontmatter and README index row both read Draft.

Its discussion: field points at https://github.com/QuantEcon/qeps/pull/7 — its own PR, now merged. So there is no open venue in which the discussion the status asserts could be happening, and no deadline was ever set. That is roughly two months in a status with no exit.

Three consequences, each observable:

• QEP-3 follow-up: proposal-* and grant-* families in place of the grant singletons #25 is blocked on an acceptance with no scheduled path. It says so in its own first line — "Deliberately not folded into QEP-3 … If adopted, it lands as an amendment to QEP-3 after acceptance" — because QEP-1's amend-in-place model applies to accepted QEPs. And its framing is already stale: it describes QEP-3 as "pending in QEP-3: Repository Naming and Types #7", which merged.
• It is cited as settled while formally unsettled. QEP-3 establishes the Adoption-is-obligations rule — "The sequenced execution checklist belongs in a tracking issue, not in this document, so completing, reordering, or dropping a step never requires amending the standard" — which QEP-1 v2 adopted and which QEP-6's Adoption section is currently drifting from. A rule doing that much work should not sit in Draft.
• Its naming families are in live use across the org — status-*, project-*, workspace-*, action-* — and the projects registry's programme and project rows lean on them. Practice has already accepted it.

Why does this need a QEP?

Not sure — let's discuss. The substantive content may need nothing; the status question is a QEP-1 process matter and may be answerable by a one-line PR.

Proposed change

Pick one, and let the record say which:

1. Accept it. One editorial PR setting status: Accepted in the frontmatter, the header table and the README row. This is the honest option if nobody holds an outstanding objection — and it unblocks QEP-3 follow-up: proposal-* and grant-* families in place of the grant singletons #25.
2. Re-open it for decision. A PR carrying QEP-3 to a decision with a deadline recorded in the description, per QEP-1 step 3.

Either way, a mechanical guard belongs with it: a QEP on main should not be able to carry status: Draft. check.mjs already validates the status enum and README parity; one added condition would have caught this at the merge commit. That half is a QEP-1 matter and is proposed in #26.