QEP-3 follow-up: `proposal-*` and `grant-*` families in place of the grant singletons

Raised while revising QEP-3 (Repository Naming and Types, pending in QuantEcon/qeps#7). Deliberately not folded into QEP-3: the QEP keeps grant-admin and grant-fundraising as reserved singletons (§4) so the naming standard can proceed, and this issue holds the design question for a proper discussion. If adopted, it lands as an amendment to QEP-3 after acceptance.

The question

Should grants be managed as repo families — one repository per proposal and one per awarded grant — instead of as folders inside the two singletons?

Today

Three observations from the live repos:

• The fundraising README already prescribes a per-grant repo — "if a proposal needs to be worked on with external stakeholders then a repository should be set up using grant-fundraising.{name}". Under QEP-3 rule 4 that dotted form is non-compliant, so the demand needs a compliant home.
• A grant's history splits across the two repos at award: the folder physically moves from grant-fundraising to grant-admin.
• Archived proposal folders are already dated by year and month (2023-03-numfocus-smalldevgrant, 2023-06-numfocus-smalldevgrant) because two proposals to the same funder collided within a year.

There is also a live proposal.computational-economic-sciences repo (2022, a Centre proposal, empty stub) — a proposal type already exists in the wild with no registry row.

Proposal under discussion

Two types in Supporting, beside contractor-{name}. The split is by kind of object, not by status: a proposal is a document addressed outward and worked to a decision; a grant is an award under administration. This is the same event/ledger distinction QEP-3 draws between audit-* and compliance-*.

Boundary sentence: a proposal is addressed outward; an internal initiative is a project-*, however it is funded.

Award is a succession, not a rename, consistent with QEP-3 §5 ("renames never transmute types"): the proposal repo freezes with the submitted document and a new grant-* repo opens with it copied in — the folder-move that happens today, lifted to repo level. The proposal date is the submission (or target) month; the grant date is the award month.

The singletons would have to change, since grant-admin beside a grant-* family reads as "the grant named admin". The QEP's existing pattern is project-* family with a projects index, giving grants (the awards registry — today's grant-admin README tables) and proposals (pipeline and ideas wiki — today's grant-fundraising), with redirects from the old names.

What the change buys and costs

Buys: one repo per grant from award to closeout with a stable name; per-grant access control (a co-PI or fiscal host sees one grant, not the ledger); a compliant replacement for the grant-fundraising.{name} escape hatch; a type for proposal.*; status that matters (in development → awarded) encoded as a type change, with declined/closed signalled by archival as elsewhere in QEP-3.

Costs: ~10–15 small private repos over a decade, mostly archived; the cross-grant view becomes an index README that must be kept; two reserved names the team knows are renamed to two others; migration is a split, which §5 has no rule for.

Open questions

1. One index singleton or two (grants + proposals, or a single funding)?
2. Threshold for a proposal to get its own repo — suggested: a named recipient and a target date; ideas stay in the wiki.
3. Is {mm} needed on grant-*, or is the award year enough? (Consistency with QEP-3's one date grammar argues for keeping it.)
4. Migration: new proposals and grants get repos from adoption; is the live Chow grant worth splitting out; the 2014/2016 archived grants stay as folders in the index. No bulk split.
5. Alternative to record if rejected: leave grants as folders and instead register grants/proposals as the only names, dropping the grant-fundraising.{name} hatch from the manual.

Start with QEP-3, especially §§4–5, then compare the grant-fundraising and grant-admin repositories and the existing proposal.computational-economic-sciences repository. This issue is ready only after the open design questions receive a decision; done means recording the accepted model as a QEP-3 amendment, or documenting the rejected alternative.