Per QEP-1, an optional discussion issue preceding a draft. The question: should the org's issue-type set carry a Proposal type? Raised 2026-09-08 alongside #24's settled position that a Programme QEP is to be drafted — the two are separate questions about the same set, and deciding them apart is how a type set ends up with members nobody designed together.
The case for
Findability, which is a first-class reason for a type rather than a usability footnote. The Project type was introduced precisely as "the discovery signal and the filter — type:Project in any issue list, org-wide". Someone scanning meta for open proposals does not naturally reach for type:Decision, and that is the same argument that created the newest member of the set.
The population is real and larger than the one that reopened the Programme question. The 2026-09-08 structure audit over the org's 123 tracker-shaped open issues puts Proposal: as the fourth commonest title convention — 12 issues, 10% — behind only no convention, PROJECT:/PRJ: and Work plan. A live search returns 16 open issues with Proposal in the title. By comparison the Programme case rests on five front doors, two of which turned out not to be programmes.
There is a structural difference from Decision, not only a rhetorical one. A Decision blocks: QEP-6 §4 makes work that cannot start before a choice blocked-by it, and leaving one open has a cost. A proposal blocks nothing — if nobody acts, nothing happens, and the default outcome is no. Different relationship to other work, different consequence of being ignored.
The case against
Proliferation. Task / Project / Decision, plus Programme if QEP-7 introduces it, plus Proposal, is five org-wide types. QEP-6 §2 deliberately reduced to three and disabled Bug and Feature. Every type is metadata every contributor must learn and every consumer must branch on.
It may be a stage rather than a kind. Once resolved, an accepted proposal and a decided decision look identical: an issue closed completed with the outcome recorded in it. If the distinction only exists while the issue is open, that is a state, and QEP-6's axis is what kind of object this is, not where it is in its life.
Decision genuinely fits the two live cases. QuantEcon/meta#332 ("Proposal: GitHub Projects as QuantEcon's PM + reporting layer") was open while the choice was pending, decided as ruling D2, and the choice is now recorded on the issue — exactly QEP-6 §2's definition. QuantEcon/meta#336 ("Proposal: a single canonical datasets repository") was decided and executed: data-lectures exists and three registered projects came out of it.
A cheaper mechanism already works. in:title Proposal returns those 16 today. It is weaker than a type because it depends on title discipline — and the same audit measuring 13 different title conventions in use is exactly the drift QEP-6 was written to stop — but it is not nothing, and it costs no metadata.
What a decision needs to settle
- Does
Proposal pass QEP-6 §2's admission test — does closing one mean something distinct from closing a Decision? The blocking difference above is the strongest candidate.
- Is it a kind or a stage? If a resolved proposal is indistinguishable from a resolved decision, does the type earn its place on the open phase alone?
- If yes, is
Proposal the right word? Alternatives considered and why each reads worse: Discussion collides with GitHub Discussions; RFC imports a convention this org does not use and QEP-1 already owns the formal-proposal lifecycle; Idea understates something with a worked argument attached. Proposal matches the title convention already in use on 16 open issues.
- Where is the boundary against QEP-1? A proposal that should become a QEP has a venue already — a discussion issue in this repository, like this one. Does a type add anything there, or is it only for org proposals that stay in
meta?
- If no, should the title convention be codified instead, so
in:title is reliable rather than incidental?
Not blocked on this
Two issues are deliberately left untyped pending the outcome: QuantEcon/meta#332 and QuantEcon/meta#336. Typing them Decision now and possibly Proposal later is churn, and this org has already reversed one typing today.
Separately and regardless of the outcome: both were retired as programme front doors in QuantEcon/status-projects#129, because a proposal — decided or not — is not a venue where a programme's projects coordinate. That question is QuantEcon/status-projects#113 and does not wait on this one.
Per QEP-1, an optional discussion issue preceding a draft. The question: should the org's issue-type set carry a
Proposaltype? Raised 2026-09-08 alongside #24's settled position that a Programme QEP is to be drafted — the two are separate questions about the same set, and deciding them apart is how a type set ends up with members nobody designed together.The case for
Findability, which is a first-class reason for a type rather than a usability footnote. The
Projecttype was introduced precisely as "the discovery signal and the filter —type:Projectin any issue list, org-wide". Someone scanning meta for open proposals does not naturally reach fortype:Decision, and that is the same argument that created the newest member of the set.The population is real and larger than the one that reopened the Programme question. The 2026-09-08 structure audit over the org's 123 tracker-shaped open issues puts
Proposal:as the fourth commonest title convention — 12 issues, 10% — behind only no convention,PROJECT:/PRJ:andWork plan. A live search returns 16 open issues with Proposal in the title. By comparison the Programme case rests on five front doors, two of which turned out not to be programmes.There is a structural difference from
Decision, not only a rhetorical one. ADecisionblocks: QEP-6 §4 makes work that cannot start before a choiceblocked-byit, and leaving one open has a cost. A proposal blocks nothing — if nobody acts, nothing happens, and the default outcome is no. Different relationship to other work, different consequence of being ignored.The case against
Proliferation.
Task/Project/Decision, plusProgrammeif QEP-7 introduces it, plusProposal, is five org-wide types. QEP-6 §2 deliberately reduced to three and disabledBugandFeature. Every type is metadata every contributor must learn and every consumer must branch on.It may be a stage rather than a kind. Once resolved, an accepted proposal and a decided decision look identical: an issue closed
completedwith the outcome recorded in it. If the distinction only exists while the issue is open, that is a state, and QEP-6's axis is what kind of object this is, not where it is in its life.Decisiongenuinely fits the two live cases. QuantEcon/meta#332 ("Proposal: GitHub Projects as QuantEcon's PM + reporting layer") was open while the choice was pending, decided as ruling D2, and the choice is now recorded on the issue — exactly QEP-6 §2's definition. QuantEcon/meta#336 ("Proposal: a single canonical datasets repository") was decided and executed:data-lecturesexists and three registered projects came out of it.A cheaper mechanism already works.
in:title Proposalreturns those 16 today. It is weaker than a type because it depends on title discipline — and the same audit measuring 13 different title conventions in use is exactly the drift QEP-6 was written to stop — but it is not nothing, and it costs no metadata.What a decision needs to settle
Proposalpass QEP-6 §2's admission test — does closing one mean something distinct from closing aDecision? The blocking difference above is the strongest candidate.Proposalthe right word? Alternatives considered and why each reads worse:Discussioncollides with GitHub Discussions;RFCimports a convention this org does not use and QEP-1 already owns the formal-proposal lifecycle;Ideaunderstates something with a worked argument attached.Proposalmatches the title convention already in use on 16 open issues.meta?in:titleis reliable rather than incidental?Not blocked on this
Two issues are deliberately left untyped pending the outcome: QuantEcon/meta#332 and QuantEcon/meta#336. Typing them
Decisionnow and possiblyProposallater is churn, and this org has already reversed one typing today.Separately and regardless of the outcome: both were retired as programme front doors in QuantEcon/status-projects#129, because a proposal — decided or not — is not a venue where a programme's projects coordinate. That question is QuantEcon/status-projects#113 and does not wait on this one.