How do you run a call for papers?
By Donghui Qian (Milo)Updated 25 September 20265 min read
Short answer
Work backwards from the day the programme must be public: that fixes when decisions are due, which fixes when submissions close. Ask only what reviewers will score, give every proposal at least two reviewers with a written rubric, handle conflicts of interest before anyone reads, and send every submitter a decision — including the rejections.
A call for papers looks like a form with a deadline. It is really a promise to several hundred people that their work will be read fairly and answered on time — and most of the pain comes from dates that were never worked out and a review process that was invented after the proposals arrived.
This guide covers the whole run: deadlines, the form, review, decisions, and what happens after acceptance. It applies whatever tool you use, ours included.
Set the dates backwards
Every date in a call depends on one other date: when the programme has to be public. That is usually driven by marketing — the day you need speaker names to sell tickets — or, for academic meetings, by when authors need a decision to book travel and get funding approved. Start there and walk back.
programme public = the date marketing or authors need it
decisions sent = programme public − time to confirm speakers and build the grid
review closes = decisions sent − time for chairs to reconcile scores
submissions close = review closes − review window
review window ≥ (proposals × reviewers per proposal ÷ reviewers)
× time per review ÷ hours each reviewer will really give
The last line is the one that gets skipped. Reviewers are usually volunteers with day jobs; if the arithmetic says each of them needs a full working day, the window has to be long enough for that day to happen. Publish Decisions by alongside the deadline — it is the date submitters plan around, and missing it is what they remember.
Decide now what an extension means. Extending the deadline squeezes the review window, not the programme date, unless you move both.
Ask only what will be scored
Every field on the form costs the submitter time and the reviewer attention. The test for each question is simple: will a reviewer or chair use this to decide?
| Ask | Why |
|---|---|
| Title and abstract, with a stated length | What reviewers score. A length limit keeps proposals comparable |
| Format and length of the session | Talk, panel, workshop — the grid needs it, and a good idea in the wrong format is a different decision |
| Track or topic | Routes the proposal to the right reviewers and chair |
| Who it is for, and what they will leave with | The best single predictor of whether a session serves your audience |
| Speaker bio and prior speaking | Useful when experience matters for the slot; leave it out for blind review |
| Availability and constraints | Travel, dates they cannot do, accessibility needs — cheaper to know now than after acceptance |
Put everything else — slides, headshots, final bios — after acceptance. Asking for slides at submission mostly filters out busy people who would have given good talks.
Design the review before the proposals arrive
- At least two reviewers per proposal. One reviewer is an opinion; two show you where people disagree, which is where the chair's time should go.
- A written rubric. Three or four criteria — relevance to the audience, originality, clarity, the speaker's ability to deliver it — each with what a low and a high score look like. Without one, scores measure the reviewer, not the proposal.
- Conflicts of interest first. Ask reviewers to declare employers, co-authors and competitors before assignment, and do not assign those proposals to them.
- Decide on blind review deliberately. Hiding names reduces bias toward known speakers; it also hides context some tracks need. Either is defensible; switching halfway is not.
- Reviewers should not see each other's scores until they have scored. Seeing a colleague's 9 before reading a proposal is not a second opinion.
Track chairs sit between the reviewers and the programme committee: they read the scores and comments for their track, resolve disagreements, and recommend. A shortlist per track is far easier to turn into a programme than one ranked list of everything.
Scores inform the decision; they do not make it
A pure top-N by average score produces a programme of similar talks by similar speakers. Use scores to find the strong proposals, then build the programme deliberately:
- Balance across tracks and formats, so no room runs four lectures in a row.
- Check for audience collisions — two strong proposals for the same people may belong on different days, or one may be the better of the two.
- Keep a reserve list. Speakers withdraw. A named backup for each slot turns a cancellation into an email rather than a scramble.
- Record why. A one-line reason per decision is what lets you answer a disappointed submitter, and what next year's committee needs.
Tell everyone, including the people you turn down
Silence is the worst decision. Send every submitter an answer on or before the date you published:
- Accepted
- What happens next and by when: confirm attendance, registration terms for speakers, materials deadline, and the session's date if you have it.
- Revise
- What would make it work, and the date the revised version is due. Use sparingly — it doubles the work for both sides.
- Not selected
- A clear no, the number of submissions if you can share it, and whether they may submit next year. A sentence from the reviewers' comments is kinder than a template.
After acceptance
- Confirm, then publish. Do not announce a speaker who has not confirmed attendance.
- One deadline for materials, with slides, final bio and headshot collected in one place rather than by email thread.
- Keep the record. Next year starts with the speakers who delivered, the proposals that nearly made it, and the reviewers who reviewed on time.
Frequently asked questions
Work it out backwards rather than pick a number. Fix the date the programme must be public, subtract the time to confirm speakers and build the grid, then the time for chairs to reconcile scores, then a review window long enough for your reviewers to actually do the reading. What is left before that is how long submissions can stay open.
At least two, so that a single opinion is never the decision and disagreements are visible. Check the load before promising it: proposals multiplied by reviewers per proposal, divided by the number of reviewers, is how many each person must read.
Blind review reduces bias toward well-known names and is common in academic meetings; open review lets reviewers weigh a speaker's experience, which some industry tracks need. Choose one deliberately before proposals arrive and apply it to the whole call.
Only what reviewers will score: title, an abstract with a stated length, session format and length, track, who the session is for and what they will leave with, and the speaker's availability. Leave slides, headshots and final bios until after acceptance.
Yes. Every submitter should get a decision on or before the date you published. A clear no, ideally with a line from the reviewers' comments and whether they can submit next year, protects the call's reputation for the next edition.