Proposal
Create QuantEcon/workspace-books — a private fleet bench for the book family, on the same model as workspace-lectures: a manifest naming the member repos, a thin runner for cross-repo commands, and coordination issues for changes that span several books. Each book repo keeps its own remote, history and PRs; the workspace only operates on them together. It would be the second member of the workspace-* type.
Why now
QEP-3 (QuantEcon/qeps#7) briefly removed the workspace-* type on the stated ground that the family had zero members. That was wrong — workspace-lectures is the member — and the type is restored in the amended draft (commit f4dcbfc), together with its boundary rule: a project-* repo is organized around a goal; a workspace-* repo is organized around a fleet. Projects close when their goal is met; a workspace persists as long as the family and outlives every project that passes through it. The books are a fleet in exactly that sense — there is no goal whose completion would retire them.
Per QEP-3 §5, this issue is the "proposed in its own tracker" step, and the QEP itself will keep naming one member until this repo exists: in-flight work is cited as in-flight, not as state.
Does the family pass the workspace-ready test?
QEP-3's criteria, assessed against the live repos:
| Criterion |
Verdict |
| Membership is stable |
Yes. Seven live book-* repos; the last addition was book-sargent-1993-bounded-rationality-in-macro (July 2026) and nothing has been retired since book-dp1-public-companion and book-networks-1 were archived. |
| Repos are structurally homogeneous |
Partly — three homogeneous clusters rather than one. LaTeX manuscripts (book-dp1, book-dp2, book-networks: chapter .tex + figures/ + common_symbols.tex); MyST digitisations (book-childs-1947-us-government-securities, book-sargent-1993-bounded-rationality-in-macro: myst.yml + uv.lock + deploy.yml, near-identical to each other); public companions (book-dp-public, book-networks-public: website/ + pdf/ + ci.yml + publish.yml). This is the weakest of the four criteria and worth deciding explicitly before scaffolding. |
| Coordination tasks recur mechanically |
Yes — see the next section. |
| Development happens upstream in the member repos |
Yes. Authoring is per-book; nothing would be written in the workspace itself. |
The recurring work a bench would carry
- Shared-CI migration.
book-dp-public/publish.yml deploys with peaceiris/actions-gh-pages@v3 and serves dp.quantecon.org; book-networks-public is the same shape. Neither consumes quantecon/actions/publish-gh-pages. This is the same migration workspace-lectures is running for the lecture family (QuantEcon/workspace-lectures#31), and the same version-policy question follows it.
- Action-version drift.
book-sargent-1993.../deploy.yml pins actions/configure-pages@v3 and Node 18; the two MyST books will drift apart unless bumped as a set.
- The private-to-public sync pairing.
book-dp1 carries a sync.yml that pushes assets to book-dp-public; book-networks/book-networks-public are the same pairing without the automation. Standardising that is a cross-repo change by construction.
- Environment and toolchain pins.
uv.lock plus .python-version in the MyST books, environment.yml in book-networks-public — the lecture family's Anaconda-bump sweeps are the analogue.
- Estate hygiene. Dependabot coverage, label conformance under QEP-2, and the archival sweeps, all of which are per-repo chores that only make sense done across the set.
Proposed membership
Following workspace-lectures' two-class split — the test is how a change reaches the repo, not what the repo is about:
| Class |
Repos |
| Authored content (swept) |
book-dp1, book-dp2, book-networks, book-childs-1947-us-government-securities, book-sargent-1993-bounded-rationality-in-macro, book-dp-public, book-networks-public |
| Infrastructure (read, never swept) |
quantecon-book-theme, quantecon-book-theme-fixtures |
Undecided, and worth settling in this issue: quantecon-book-networks (a quantecon-book-{name} companion package under QEP-3's content rows, but consumed rather than swept), manual-lars-hansen, and whether lecture-dp / lecture-dp.monorepo belong to the lecture family or the book family.
A naming question this surfaces
QEP-3's content row reads book-{name} plus a .public companion — a dot variant, because dots encode a variant of the same content. The live repos use a dash: book-dp-public, book-networks-public. That is not drift — book-dp-public#14 was a deliberate rename into the dash form in March 2026 — so either the grammar bends to the incumbents or those two are rename candidates. Under QEP-3 §5 renames ride on active maintenance rather than a campaign, which makes standing up this workspace the natural moment to decide.
Shape, if agreed
Mirror workspace-lectures: manifest.yml as the single source of truth for membership, bin/ runner (sync, doctor, foreach, tidy), docs/adr-0001 recording the design decisions, .claude/CLAUDE.md for session orientation, and clones gitignored under repos/ and repos-infrastructure/. Nothing new needs to be designed; the open questions are membership and the two naming decisions above.
Proposal
Create
QuantEcon/workspace-books— a private fleet bench for the book family, on the same model asworkspace-lectures: a manifest naming the member repos, a thin runner for cross-repo commands, and coordination issues for changes that span several books. Each book repo keeps its own remote, history and PRs; the workspace only operates on them together. It would be the second member of theworkspace-*type.Why now
QEP-3 (QuantEcon/qeps#7) briefly removed the
workspace-*type on the stated ground that the family had zero members. That was wrong —workspace-lecturesis the member — and the type is restored in the amended draft (commit f4dcbfc), together with its boundary rule: aproject-*repo is organized around a goal; aworkspace-*repo is organized around a fleet. Projects close when their goal is met; a workspace persists as long as the family and outlives every project that passes through it. The books are a fleet in exactly that sense — there is no goal whose completion would retire them.Per QEP-3 §5, this issue is the "proposed in its own tracker" step, and the QEP itself will keep naming one member until this repo exists: in-flight work is cited as in-flight, not as state.
Does the family pass the workspace-ready test?
QEP-3's criteria, assessed against the live repos:
book-*repos; the last addition wasbook-sargent-1993-bounded-rationality-in-macro(July 2026) and nothing has been retired sincebook-dp1-public-companionandbook-networks-1were archived.book-dp1,book-dp2,book-networks: chapter.tex+figures/+common_symbols.tex); MyST digitisations (book-childs-1947-us-government-securities,book-sargent-1993-bounded-rationality-in-macro:myst.yml+uv.lock+deploy.yml, near-identical to each other); public companions (book-dp-public,book-networks-public:website/+pdf/+ci.yml+publish.yml). This is the weakest of the four criteria and worth deciding explicitly before scaffolding.The recurring work a bench would carry
book-dp-public/publish.ymldeploys withpeaceiris/actions-gh-pages@v3and servesdp.quantecon.org;book-networks-publicis the same shape. Neither consumesquantecon/actions/publish-gh-pages. This is the same migrationworkspace-lecturesis running for the lecture family (QuantEcon/workspace-lectures#31), and the same version-policy question follows it.book-sargent-1993.../deploy.ymlpinsactions/configure-pages@v3and Node 18; the two MyST books will drift apart unless bumped as a set.book-dp1carries async.ymlthat pushes assets tobook-dp-public;book-networks/book-networks-publicare the same pairing without the automation. Standardising that is a cross-repo change by construction.uv.lockplus.python-versionin the MyST books,environment.ymlinbook-networks-public— the lecture family's Anaconda-bump sweeps are the analogue.Proposed membership
Following
workspace-lectures' two-class split — the test is how a change reaches the repo, not what the repo is about:book-dp1,book-dp2,book-networks,book-childs-1947-us-government-securities,book-sargent-1993-bounded-rationality-in-macro,book-dp-public,book-networks-publicquantecon-book-theme,quantecon-book-theme-fixturesUndecided, and worth settling in this issue:
quantecon-book-networks(aquantecon-book-{name}companion package under QEP-3's content rows, but consumed rather than swept),manual-lars-hansen, and whetherlecture-dp/lecture-dp.monorepobelong to the lecture family or the book family.A naming question this surfaces
QEP-3's content row reads
book-{name}plus a.publiccompanion — a dot variant, because dots encode a variant of the same content. The live repos use a dash:book-dp-public,book-networks-public. That is not drift —book-dp-public#14was a deliberate rename into the dash form in March 2026 — so either the grammar bends to the incumbents or those two are rename candidates. Under QEP-3 §5 renames ride on active maintenance rather than a campaign, which makes standing up this workspace the natural moment to decide.Shape, if agreed
Mirror
workspace-lectures:manifest.ymlas the single source of truth for membership,bin/runner (sync,doctor,foreach,tidy),docs/adr-0001recording the design decisions,.claude/CLAUDE.mdfor session orientation, and clones gitignored underrepos/andrepos-infrastructure/. Nothing new needs to be designed; the open questions are membership and the two naming decisions above.