How not to suck at CFPs: Real-World Feedback from the Review Board

A review board for a security conference walks through its call for papers and explains what makes a proposal succeed or fail. The panel opens with submission statistics from the year: about 111 proposals from 95 speakers, mostly introductory, with some intermediate and advanced entries and a set of workshops. The panelists note that proposers often struggle to know what reviewers want.

To avoid singling out real submissions, the panel invents example abstracts and critiques them. Weak examples are vague, run only a few sentences, omit the speaker's credentials, or read like a product pitch full of buzzwords. Others are off-topic for a security audience, try to cover five subjects in a 20-minute slot, or repackage a familiar talk with new terminology. The panel recommends submitting only one or two well-developed talks, writing an outline, and choosing a title that is neither too long nor too short. They then examine a highly ranked real submission that was specific, concise, relevant, shared source code, and fit its time slot.

The closing advice is to know the audience, tailor any analogies to security, and use the notes field for detail that does not belong in the public pitch. Proposers should have a colleague read the draft, state clearly when a talk is a follow-up, and seek feedback from local groups before the window closes. Panelists stress that rejection rarely reflects poor quality, since slots are limited.