To express your interest in submitting your paper to a venue, you must register it. Registering a project starts the internal review process.

Instructions to submit

1. Pick the venue. By default, we are a core-ML lab — the bulk of submissions should go to ICML, NeurIPS, and ICLR. Their deadlines are nicely spaced out (Feb / May / September), so you should never be far from one. Specialised conferences (e.g. AAMAS) are fine if justified; AAAI is usually a last resort.
2. Register the paper in the Internal Review Board — create the venue's board if it isn't there yet — with the title and a compute estimate. Authors, the Overleaf link, and the abstract come later, at Submit the abstract — there's no first draft yet to point to.
3. If you're the main author, clear your schedule of everything else for the run‑up to the deadline.

What happens after submission

The card appears on the venue's board in Registered, visible to everyone who has it open — the board updates live. Registration does not require approval. You can move to the next stage.

Look after yourself. Exercise, sleep, and food matter through the push. A PhD life is a marathon, not a sprint.

What it means that the card is in Registered: abstract, outline, and a compute estimate exist. It hasn't been pitched to the group yet — that's the one thing standing between here and Pitched.

Instructions to submit

Every paper is pitched to the group on a fixed Pitch Day — everyone presents. A paper that hasn't been pitched by this point doesn't go forward.

1. Prepare a short pitch: the problem, the idea, what the results look like so far.
2. Link the pitch materials on the card, then click Submit pitch — a real, confirmed action, not a bare click.

What happens after submission

The card moves to Pitched, and you get a Slack DM confirming it.

Once the project has been registered (and pitched, if not in rush mode), you must submit your abstract.

Instructions to submit

1. Add your co-authors on the card. You won't be able to change them once you submit the abstract.
2. Add the Overleaf link, pointing at a first draft — we won't check it, but it needs to exist — the bulk of the work should be done by the time you submit the abstract. Read and closely follow the “How to ML Paper” guide while writing it.
3. Open the card and paste the abstract into the Abstract field. LaTeX renders live — inline math between single dollar signs, block equations between double dollar signs.
4. Assign a junior and a senior reviewer — the senior reviewer defaults to the PI. If you're not sure who's free to take the junior slot, ask on Slack.
5. Once all of that's in place, click Submit the abstract — this starts internal review and can't be undone.

What happens after submission

The card moves to Abstract and you get a Slack DM. The author list locks from here on, matching the venue's own submission. The senior reviewer (defaults to the PI) now makes a quick call — Approve or Request changes — before the card can move on to Paper.

How to review

This is a lightweight go/no-go, not a checklist: is the idea and direction sound enough to justify writing a full paper for it? The senior reviewer (defaults to the PI) makes the call directly on the card — Approve or Request changes, no checklist, just their own judgement.

Once approved, the card moves to Paper on its own — no click, no confirmation, nothing for the author to submit. If changes are requested instead, the badge shows it, and the reviewer can switch it to Approved once they're satisfied.

By when: when the venue sets its own abstract deadline, the schedule rail on the Internal Review Board marks a reviewer deadline the middle day of the 2-day internal-buffer window before that deadline's internal target — the day the senior reviewer's own call is due.

Once the abstract's been approved and the card moves to Paper, it's time for the full checklist review. Check the “How to ML Paper” guide for what a submission-ready draft looks like. The draft goes through Internal Review now — a simulated full peer review (venues are all similar), before the real one.

Instructions to submit

1. Complete the authors' checklist on the card's own page — any co-author can tick it, not just whoever registered the paper.
2. Make sure your Overleaf link grants reviewers edit or review access, not just a link to the project — a link they can't actually open won't let them finish their own checklist.
3. Once both checklists are done, click Submit the paper — this is what actually sends it to the venue, and can't be undone.

What happens after submission

The card moves straight to Rebuttal — the paper's in the venue's hands now, and the board shows a “Waiting for reviews” badge. Nothing left to click after this: once the venue's own reviews-release date passes, the badge flips itself to “In Rebuttal” and you get a Slack DM — the board watches that date for you, on a timer, the one automatic step in this whole pipeline. Posting to arXiv (next page) is optional and can happen any time from here on, whenever it's ready.

How to review

Every author ticks the Format checklist (6 items: mandatory sections, length/page limits, double-blind anonymity, the venue's own template, policy compliance). The junior and senior reviewers each independently work through the Science checklist (6 items, across 5 categories: claimed contributions, correctness, impact, limitations, related work & positioning). Both checklists live on the card's own page.

Working through the Science checklist with a coding agent? Point it at checklists/reviewers/AGENTS.md — a skeptical pre-review to speed up your own pass, not a replacement for it.

By when: same mechanism as Submit the abstract — the schedule rail on the Internal Review Board marks the reviewer deadline the middle day of the 2-day internal-buffer window before the paper's internal target.

Optional, and not tied to any deadline on the board — do this whenever the paper's ready to go public, any time after Submit the paper. Nothing here blocks or advances the card; there's no button for it any more, just a link you add.

Posting

Submitting isn't the finish line — it's one small step, not a pause. This is when the arXiv version gets prepared, and it's often the only version many readers ever see, so treat it with real care.

1. Give co-authors a week's heads-up and share a final draft before posting.
2. The final draft must include author names and affiliations, plus acknowledgments covering grants and funding bodies — the latter is crucial. See the current default here.
3. When listing your affiliation, use “BOLD, {University of Oxford / Imperial College / UCL}” whenever possible.
4. Print off the paper to check for final typos, formatting, and other issues.
5. Open-source your cleaned-up code and link the repo before you submit to arXiv.
6. Paste the resulting arXiv link onto the card's Edit fields whenever it's live (see #14 for the idea of doing the actual posting directly from the card instead, one day).

Publicity

Also whenever, also optional — the same paper deserves an audience beyond the venue's own reviewers.

1. Draft a tweet thread and share it with all authors ahead of time. Typefully can be a useful tool for this.
2. Tweets should clearly motivate the problem for a broad audience and make it easy to grasp what's happening.
3. Example tweet chains from BOLD and collaborators:
   • Chris Lu
   • Minqi Jiang
   • Jakob Foerster
4. Remember to tag @BOLD_Ox and your co-authors.
5. Consider a blog post for major breakthroughs — this is the gold standard.

While you wait: capture the loose ends

Credit to Roger Grosse for this practice.

“Now that the deadline is past, there's one more (hopefully easy) task for all of you. After a deadline push, I find it very useful to make a list of all the loose ends in the project. It's important to do it very soon after the deadline while everything is still fresh in your mind. This will save a lot of time and stress later on.”

Sometime in the next few days, start a Google Doc to track loose ends. Aim to spend about an hour on it — or build it up as you go if you're doing heavy work for the Supplemental Material deadline. Ideas for what to include: experiments you still want to run, surprising findings that need explaining, aspects of the experimental protocol you're not comfortable with, prior work to look at more carefully, things to explain better, mathematical arguments to check or make more precise, questions about notation or terminology.

What it means that the card is in Rebuttal: reviews are public — the board's own “In Rebuttal” badge and Slack DM already told you. This is the one genuinely actionable stage after submission — a real, deadline-bearing task, not just a wait.

Instructions to submit

Follow the “How to ML Rebuttal” guide closely. The venue's reviews-released and rebuttal-deadline dates, when known, are on the Internal Review Board and in its deadline .ics.

1. Link the written rebuttal document on the card, then click Submit rebuttal.

What happens after submission

The card moves to Rebuttal Submitted and you get a Slack DM — the honest name for it: the rebuttal's in, camera-ready is what's due next (assuming acceptance).

What it means that the card is in Rebuttal Submitted: the rebuttal's gone in. Reaching this stage generally means the paper's been accepted — a final, publication-ready version is due by the venue's own camera-ready deadline (cameraReadyDeadline on the board).

Instructions to submit

1. Fold in every change reviewers required, and anything promised in the rebuttal.
2. Final formatting pass — page limit, required sections, camera-ready-specific template if the venue has one.
3. Update acknowledgments and funding to their final form, same care as the arXiv version.
4. Double-check author list and affiliations are exactly right — this is usually the version that ends up in the proceedings permanently.
5. Link the submitted camera-ready version on the card, then click Submit camera-ready.

What happens after submission

The card moves to Accepted and you get a Slack DM — the last automatic move the pipeline makes.

What it means that the card is in Accepted: everything's submitted — abstract, paper, rebuttal, camera-ready. This is the terminal stage; nothing further advances it. What's left is conference prep.

Instructions

Nothing here is gated or submitted — just the practical run-up to actually presenting.

1. Poster: make one and share it with co-authors. Example posters to fork: Jakob's poster and one more. Focus on images and getting the main ideas across — posters are not papers, they're not meant to be self-explaining. You'll be standing there explaining them to people.
2. Talk: schedule a practice talk with the group if you're presenting. Slides can be Google Slides or an HTML deck — whatever's easiest to build and share with co-authors.
3. Networking: email anyone you want to talk to at the conference at least 3 weeks beforehand to set up a meeting. Join as many of the conference's social events as you can — this is mandatory, they're usually the best networking.