Working Papers in Critical Search publishes work at the intersection of history, computation, and critical approaches to political economy, empire, and environment. We are looking for scholarship that treats method and interpretation as inseparable: submissions should make their evidentiary chains explicit — where sources originate, how they have been transformed, how methods have been tested, what the data's limitations are, and which passages substantiate the interpretation.

We publish in four formats

• Draft papers — something you're developing for a traditional journal. Get feedback, establish priority, iterate in public.
• Dataset papers — you built a historical dataset. Document it, share it, get credit for it.
• Method notes — you figured out how to do something useful. Write it up so others can learn.
• Short pieces — an observation, a benchmark, a comparison. Too small for a journal but worth sharing.

What falls outside our scope

We are not the right venue for finished historical essays that gesture at computational tools without showing how they were used, or for technical demonstrations on historical material without a historical argument. We are also not a venue for very early drafts seeking developmental feedback before they have an argument; working papers should be coherent and citable in their current form, even if the underlying research is ongoing.

For the broader intellectual rationale, see the introduction to the series and the About page.

Once your PR is open, an editor reads through and leaves comments directly on the lines that need attention. Some comments are questions; others are concrete suggestions you can accept with a single click. You respond with new commits to the same branch — no new PR, no resubmission. Conversation continues in the same place until everyone's happy.

We're not running blind peer review. Editorial review here checks scope fit, asks whether the methods are documented well enough that a reader could follow them, and flags places where the argument or the evidence chain has a gap. For papers that touch areas outside the editors' direct expertise, we may invite a third reader into the PR.

Code

Include your code or describe your methods. It does not need to run on a reviewer's laptop. If you used a cluster with H100s for thirty hours, just say so.

Data

• Small data (< 10 MB): include it in a data/ folder
• Large data: host on Zenodo, Hugging Face, or another DOI repository and link to it
• Sensitive data: describe what you used and how others can access comparable sources

Compute

We welcome work at any scale — laptop, single GPU, or a cluster with weeks of runtime. Just be clear about what you used so readers can calibrate.

Minor fixes — typos, broken links, small clarifications — come in as small PRs that merge quickly and trigger a rebuild. Major revisions warrant a new version (v1.1, v2.0), a new release tag, and a new Zenodo DOI. Previous versions remain citeable at their original DOIs.

Optional: if a paper has strong technical contributions, we can help submit a PDF snapshot to arXiv.

If you've already published a draft of your paper as a Quarto site, blog post, or preprint elsewhere, just send us the URL and the source files when you're ready. We'll handle the rest in Step 03.

If you've already transferred a paper repo into the Working-Papers-in-Critical-Search organization yourself, that's fine too — let us know and we'll pick up editorial review from there. (Note: GitHub holds an internal lock on freshly-deployed Pages repos for ~15 minutes; if a transfer hangs in “Moving repository to…”, treat it as failed and email us.)