Follows the 2026-08-23 ruling on #15, which scoped the QEP to the tracker unit interface — one tracker issue, work items as native sub-issues one level down, a machine-readable status stamp, and the native Project issue type — while leaving the practice to the qe skills.
A convention that only ever applies to trackers written after it lands leaves the existing estate silently non-conforming, and the dashboard collector reads the estate, not the new arrivals. So the QEP needs a companion activity: a one-time compliance review of existing trackers, and a check that can be re-run so conformance does not decay.
Why this is worth filing now rather than after the QEP
Because the gap is already measurable. Every element of the proposed unit except the machine-readable stamp can be queried today via GraphQL, and the Project issue type already exists at both org and repo level across QuantEcon — it is simply unused. So the compliance review can be prototyped against the current estate while the QEP is still in draft, and what it finds is exactly the field evidence #15's suggested path asks for.
A worked example — field evidence from a live tracker
QuantEcon/quantecon-theme.mystmd#147 is an actively-maintained tracker for a project-duration cutover gate, revised three times on 2026-08-26. Measured against the proposed unit:
| Element of the unit |
State of #147 |
Verdict |
| One tracker issue for the project |
yes — sole tracker, milestone kept in sync with it |
conforms |
| Work items as native sub-issues, one level down |
9 sub-issues (7 open, 2 closed), no nesting |
conforms |
Native Project issue type |
none — untyped, and carries no labels either |
does not conform |
| Machine-readable status stamp |
human prose only: **Revised:** 2026-08-26 13:15 AEST |
does not conform |
The interesting part is the shape of the failure. This is a well-maintained tracker — it satisfies the structural half of the unit without anyone having aimed at the convention, because native sub-issues are the natural way to build such a thing. What it misses is precisely the two machine-readable elements, which are the ones the collector depends on and the only ones a human author gains nothing from. That asymmetry is an argument for automating the check rather than relying on authors, and it suggests the migration cost for conforming repos is small and mechanical: set a type, reformat a stamp.
Bearing on the open ordering question
#15's fourth question asks whether the unit expresses order. #147 does express order, and entirely in prose: its body opens with a "Next session — resume here" section naming which sub-issue leads and why, added because the sub-issue list alone could not convey it. The remaining six sub-issues have a real dependency structure (one pair must ship together; two are independent and can run in parallel; one is a decision with no implementation) that no ordering of a flat list captures.
So the field answer looks like yes, order is load-bearing, and no, a linear order is not sufficient — the honest structure is a partial order, not a sequence. Worth weighing before the QEP settles on a mechanism, since "next" is easy to encode and "these two are independent" is not.
What the compliance review would produce
- A pass over every registered project tracker, reporting per-tracker conformance against each element of the unit, with the non-conforming ones tiered by how mechanical the fix is.
- A count of the estate-wide gap, which is the input to deciding whether the QEP mandates migration or grandfathers existing trackers.
- The check itself, re-runnable — ideally the same query the dashboard collector already needs, so conformance is a by-product of collection rather than a separate audit.
Sequencing
This should not start before the QEP fixes the unit; a review against a moving target has to be redone. But prototyping the query against the current estate is useful now, because its findings are evidence for the draft — particularly on the ordering question, where a survey of how existing trackers express order would settle whether a mechanism is needed at all.
Related: #15 (the discussion and its scoping ruling), #11 (the QEP-2 field report on type labels for plan/tracking issues, which the type element above depends on).
Follows the 2026-08-23 ruling on #15, which scoped the QEP to the tracker unit interface — one tracker issue, work items as native sub-issues one level down, a machine-readable status stamp, and the native
Projectissue type — while leaving the practice to theqeskills.A convention that only ever applies to trackers written after it lands leaves the existing estate silently non-conforming, and the dashboard collector reads the estate, not the new arrivals. So the QEP needs a companion activity: a one-time compliance review of existing trackers, and a check that can be re-run so conformance does not decay.
Why this is worth filing now rather than after the QEP
Because the gap is already measurable. Every element of the proposed unit except the machine-readable stamp can be queried today via GraphQL, and the
Projectissue type already exists at both org and repo level across QuantEcon — it is simply unused. So the compliance review can be prototyped against the current estate while the QEP is still in draft, and what it finds is exactly the field evidence #15's suggested path asks for.A worked example — field evidence from a live tracker
QuantEcon/quantecon-theme.mystmd#147 is an actively-maintained tracker for a project-duration cutover gate, revised three times on 2026-08-26. Measured against the proposed unit:
Projectissue type**Revised:** 2026-08-26 13:15 AESTThe interesting part is the shape of the failure. This is a well-maintained tracker — it satisfies the structural half of the unit without anyone having aimed at the convention, because native sub-issues are the natural way to build such a thing. What it misses is precisely the two machine-readable elements, which are the ones the collector depends on and the only ones a human author gains nothing from. That asymmetry is an argument for automating the check rather than relying on authors, and it suggests the migration cost for conforming repos is small and mechanical: set a type, reformat a stamp.
Bearing on the open ordering question
#15's fourth question asks whether the unit expresses order. #147 does express order, and entirely in prose: its body opens with a "Next session — resume here" section naming which sub-issue leads and why, added because the sub-issue list alone could not convey it. The remaining six sub-issues have a real dependency structure (one pair must ship together; two are independent and can run in parallel; one is a decision with no implementation) that no ordering of a flat list captures.
So the field answer looks like yes, order is load-bearing, and no, a linear order is not sufficient — the honest structure is a partial order, not a sequence. Worth weighing before the QEP settles on a mechanism, since "next" is easy to encode and "these two are independent" is not.
What the compliance review would produce
Sequencing
This should not start before the QEP fixes the unit; a review against a moving target has to be redone. But prototyping the query against the current estate is useful now, because its findings are evidence for the draft — particularly on the ordering question, where a survey of how existing trackers express order would settle whether a mechanism is needed at all.
Related: #15 (the discussion and its scoping ruling), #11 (the QEP-2 field report on type labels for plan/tracking issues, which the type element above depends on).