Conference talks are the cheapest professional visibility available in this field, and the barrier is a form most people never fill in. Ars Electronica, SIGGRAPH, ICLC, NIME, CHI, ISEA, Sónar+D, MUTEK, and dozens of smaller festivals and meetups run open calls, most of them free to enter.
A proposal is a piece of persuasive writing with a known audience and a known set of failure modes. It is learnable.
goobar on the mechanics of a proposal, with a template.
First: understand what the reviewer is doing
A reviewer has somewhere between fifty and four hundred proposals and an afternoon. They are reading fast, in a spreadsheet or a review tool, and they are answering roughly four questions:
- Is this a talk, or a topic?
- Will the audience leave with something?
- Can this person actually deliver it?
- Does it fit the programme we are building?
Almost every rejection is a failure on one of those four, and the first is by far the most common.
The difference between a topic and a talk
This is the single most valuable distinction, and getting it right will do more than everything else combined.
A topic is a subject area. “Machine learning in interactive installations.” “Building with WebGPU.” “Sustainable practice for digital artists.”
A talk is an argument, a story, or a demonstrable claim. “We replaced our computer-vision pipeline with a 4MB model and the installation stopped crashing — here is what we gave up.” “WebGPU’s compute shaders let us run a million-particle system in a browser; three of our four attempts failed first, and the reasons are instructive.”
The test: can someone disagree with it? If not, it is a topic. A topic has no shape, so the reviewer cannot picture the talk, so they cannot picture whether it is good.
The second test: could anyone else give this talk? If your proposal could be delivered by any competent person who read the documentation, it is a tutorial someone can already Google. If it depends on something you did, something that happened to you, or a position you hold that others don’t — it is yours.
The anatomy of a proposal
Most calls ask for some subset of: title, short abstract (50–100 words), long description (200–500), audience takeaways, audience level, and a bio. Here is what each one is for.
Title
Concrete beats clever. A title should let a reviewer — and later an attendee scanning a schedule — know what they’re getting.
- ❌ “Beyond the Canvas”
- ❌ “Rethinking Interaction”
- ✅ “Six Months of a Kinetic Sculpture in a Public Library: What Broke”
- ✅ “Running Stable Diffusion on a $12 Microcontroller”
Avoid a colon-plus-subtitle that says nothing after the colon. If you want a poetic title, earn it with a subtitle that is purely factual.
Abstract (the part that gets read)
Assume this is the only thing some reviewers read. Structure it as four sentences:
- The situation — what you were doing and why it mattered
- The problem or tension — what was hard, surprising, or contested
- What you did — the specific thing, named
- What the audience gets — stated as a takeaway
Write it in the past tense about real things. Present-tense promises about what you will “explore” and “examine” are the signature of a proposal with nothing in it.
Long description
Here you can give the actual structure. Reviewers love an outline because it proves the talk exists:
1. The commission and the constraint (5 min)
- Public library, 9 months, no attendant, no network
2. What we tried first, and why it failed (10 min)
- Pi + webcam; three failure modes with photos
3. The rewrite (10 min)
- Moved to an ESP32-S3, dropped resolution, gained reliability
4. What I'd tell you to do differently (5 min)
5. Q&A (5 min)
Five minutes of setup, twenty of substance, five of Q&A. An outline with timings answers question 3 — can this person deliver it — more convincingly than any bio.
Takeaways
Write these as things the audience will be able to do or decide, not things they will “understand.”
- ❌ “Attendees will gain an understanding of edge AI.”
- ✅ “Attendees will be able to judge whether their project should run on a microcontroller or a Pi, and will know the three failure modes that decide it.”
Bio
Third person, short, and relevant to this talk. The reviewer is checking credibility on this specific subject, not reading a CV. Two or three sentences. Link one thing — the project the talk is about, ideally.
The failure modes, in order of frequency
Vagueness. Fixed by naming things. Which model, which board, which venue, which library, how many, how long, what it cost.
No takeaway. Fixed by writing the takeaway first and building the talk toward it.
A sales pitch. If your talk is about a product you sell, reviewers will smell it and most programmes will reject it. You can talk about how you built the thing. You cannot talk about why people should buy it.
Scope for a keynote in a 25-minute slot. “The History and Future of Generative Art” is not a conference talk, it is a book. Narrow until it is uncomfortably specific, then narrow once more.
Ignoring the theme. If the call has a theme — ICLC 2027’s is Dialogues — address it explicitly, in the abstract, in its own words. Reviewers are building a coherent programme and a proposal that fits the frame is doing them a favour.
Missing the actual requirements. Word limits, anonymisation, templates, whether a technical rider is required. Many calls desk-reject on format before anyone reads the content. Read the call twice.
Practical tactics
Submit to the smallest relevant venue first. A local meetup or a regional festival is a much easier acceptance, and once you have delivered a talk twice it is both better and much easier to pitch. Nobody’s first talk should be at SIGGRAPH.
Propose the talk you already gave informally. The explanation you have given four colleagues, or the post-mortem you wrote for your own team, is usually a better talk than anything you invent for a call.
Propose two, not one. Many programmes accept the second-choice topic because it fills a gap. It costs you an hour.
Include the failure. Talks about what went wrong are consistently more useful, better attended, and more memorable than talks about success — and they are much rarer, because they are harder to volunteer. This is the single biggest edge available to a first-time speaker.
Write the proposal before you finish the work, but only if the work is real. Deadlines are months before the event; you do not need the project finished. You do need it to exist.
After submission
Notifications slip. Check the call’s stated date, add two weeks, then ask politely.
Rejection is usually about fit. Programmes balance topics, formats, speaker demographics and levels. A good proposal gets rejected because there were already two talks on that subject. Send it somewhere else, unchanged. Most people rewrite from scratch or give up; both are mistakes.
If accepted, ask what slot and what audience. A 10-minute lightning slot and a 45-minute session are different talks, and a proposal is not a contract about length.