Raised while revising QEP-3 (Repository Naming and Types, pending in #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
| Repo |
Holds |
Volume |
grant-fundraising |
proposals as folders (jupyteach-ai, teach-the-teacher, …), ideas in the wiki, _archive/ for declined, _awarded/ |
~10 proposals since 2021 |
grant-admin |
awarded grants as folders (chow/, amazon-psl/2022-grant1, …), _archive/ for finalised |
6 awards since 2014 |
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-*.
| Prefix |
Meaning |
Visibility |
Lifecycle |
proposal-{yyyy}-{mm}-{name} |
a proposal to an external party — funding, partnership, an institute — worked to a decision |
private |
frozen at the decision; archived (an award is succeeded by a grant-*) |
grant-{yyyy}-{mm}-{name} |
an awarded grant under administration: agreement, budget, reports |
private |
grant-scoped — archived at closeout |
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
- One index singleton or two (
grants + proposals, or a single funding)?
- Threshold for a proposal to get its own repo — suggested: a named recipient and a target date; ideas stay in the wiki.
- Is
{mm} needed on grant-*, or is the award year enough? (Consistency with QEP-3's one date grammar argues for keeping it.)
- 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.
- 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.
Raised while revising QEP-3 (Repository Naming and Types, pending in #7). Deliberately not folded into QEP-3: the QEP keeps
grant-adminandgrant-fundraisingas 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
grant-fundraisingjupyteach-ai,teach-the-teacher, …), ideas in the wiki,_archive/for declined,_awarded/grant-adminchow/,amazon-psl/2022-grant1, …),_archive/for finalisedThree observations from the live repos:
grant-fundraising.{name}". Under QEP-3 rule 4 that dotted form is non-compliant, so the demand needs a compliant home.grant-fundraisingtogrant-admin.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-sciencesrepo (2022, a Centre proposal, empty stub) — aproposaltype 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 betweenaudit-*andcompliance-*.proposal-{yyyy}-{mm}-{name}grant-*)grant-{yyyy}-{mm}-{name}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-adminbeside agrant-*family reads as "the grant named admin". The QEP's existing pattern isproject-*family with aprojectsindex, givinggrants(the awards registry — today's grant-admin README tables) andproposals(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 forproposal.*; 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
grants+proposals, or a singlefunding)?{mm}needed ongrant-*, or is the award year enough? (Consistency with QEP-3's one date grammar argues for keeping it.)grants/proposalsas the only names, dropping thegrant-fundraising.{name}hatch from the manual.