---
title: Conference Talk Proposal Examples
teaser: 'Opening up the archives! All of Joël Quenneville''s conference talk proposals,
both accepted and rejected.
'
tags: conferences,writing
author: Joël Quenneville
published_on: 2020-02-06
---
Giving a conference talk is a professional goal of many programmers. Most
conferences put out a public call for proposals (CFP) where you can submit an
abstract of what you plan to talk about. With any luck, the committee will like
what you wrote and you will be selected as a speaker!
So how do you write a good CFP submission and how can you increase your odds of
getting a proposal accepted? There are some great articles out there already
with advice on how to improve your proposal such as Sarah Mei's [What Your
Conference Proposal is Missing] or Noel Rappin's [What I Learned from Reading
429 Conference Proposals].
Unfortunately, there aren't many good examples of CFP submissions out there. To
remedy that, I am opening up all of my submissions, both accepted and rejected
talks.
I'm also highlighting a few that are good examples of lessons I've learned about
submitting a talk idea. While I can't say for sure why a particular talk got
accepted or rejected, I have noticed patterns over time.
Talk proposals generally consist of an abstract, which will become the blurb
attendees see about your talk if it gets accepted, and some other fields that
are only seen by the CFP committee and vary from one conference to another. I've
linked to the full proposal for each talk. Additionally, I've quoted the
abstract of those proposals that serve as examples for a particular lesson
learned.
[What Your Conference Proposal is Missing]: http://www.sarahmei.com/blog/2014/04/07/what-your-conference-proposal-is-missing/
[What I Learned from Reading 429 Conference Proposals]: http://www.noelrappin.com/railsrx/2014/3/17/what-i-learned-from-reading-429-conference-proposals
## Tell a story
> **Rolling Random Romans**
>
> Dive into Elm's random generators on a quest to build a historically accurate
> Roman random name generator for the goddess Juno, based on a series of
> dependent and independent constraints.
>
> -- [Full proposal][Rolling Random Romans]
This talk was inspired by a personal project I had done that combined learning
about Elm and ancient Roman history. I took the project and wrapped it with a
narrative device that fit the theme. By telling a story, the talk becomes much
more intriguing and memorable to both the committee and the audience at large
than it would have been as a straightforward "explain random generators" talk.
## Good topics get rejected
> **Real World JSON Decoding**
>
> The real world is messy and servers are no exception. The data we get is
> inconsistent, oddly-shaped, and sometimes flat-out wrong. Elm's JSON decoders
> give us the tools to deal with all of these scenarios and more.
>
> The world beyond the nicely contrived examples of decoding tutorials is
> riddled with challenges such as decoding union types, conditional decoding,
> and handling bad data. Join me as we attempt to decode data into something our
> Elm apps can work with in a series of real-world examples. Along the way,
> we'll level up your JSON skills till you're slinging decoders around that can
> convert anything the server wants to throw at you!
>
> -- [Full proposal][Real World JSON Decoding]
I liked this proposal and it addressed a real need in the community for
practical content that goes beyond simple tutorials. I submitted it to Elm
Europe 2018 (they chose another of my proposals), ElmConf 2018, and ElmConf
2019 but no one picked it up.
Sometimes you have a talk that you think is a great fit with a decent pitch and
it won't get picked. **Don't get discouraged**. Even people who you see speaking
a lot get many rejections. As you will see in the full list at the bottom of
this article, a lot of my talks have been rejected.
## Submit multiple proposals
> **Working with Maybe**
>
> One of the selling points of Elm is that you cannot get null errors. Maybe is
> what allows Elm to avoid this billion-dollar problem entirely. It's a
> beautiful solution.
> But it doesn't take too long before your code is one long ugly nested case
> statement checking Maybes at every level. Surely this can't be right. There
> must be a better way.
>
> We have an array of tools at our disposal to solve this problem, from simple
> convenience functions all the way to eliminating Maybe altogether in favor of
> other constructs. Join me on a whirlwind tour of these solutions and take back
> control of your codebase.
>
> -- [Full proposal][Working with Maybe]
Most conferences don't limit you to a single proposal. If you have several
ideas, submit them all! Don't sacrifice quality for quantity but if you can have
both, it increases your chances of getting accepted. I regularly submit **3-5
proposals** to conferences.
_Working with Maybe_ was the last of several talks I submitted to Elm Europe
2018, and it was selected. I added this proposal almost as an afterthought so
this choice was unexpected for me. The talk turned out to be one of my best.
Sometimes CFP committees will surprise you with what they pick! They know their
needs and audience better than you do, so give them options.
## Know your audience
> **Data vs Metadata**
>
> What do types like `Maybe` and `RemoteData` have in common? They both augment
> some other value with contextual metadata (presence and request status
> respectively).
>
> Using this mental model, we will look at various ways we can design data
> structures that represent contextual metadata as well as strategies that can
> keep that information out of our core business functions. Has `Maybe` taken
> over your codebase? Do you need to model a complex data synchronization
> problem? This talk will equip you with the mental model and tools to deal with
> these problems and more.
>
> -- [Full proposal][Data vs Metadata]
It's important to do your research beforehand. What kinds of talks is a
conference looking for? Are there any types of talks they are looking to avoid?
It is possible to submit a great submission for a talk that a conference is just
not interested in. It's not that your idea is bad, just that you submitted it to
the **wrong audience**.
Elm conferences tend to prefer talks that are on the more practical and concrete
side of things. In _Data vs Metadata_ I was excited to discuss a mental model
that has been quite helpful for me. While I tried to give it a practical slant,
it is still pretty theoretical.
I submitted it to ElmConf 2018 but it was rejected. If I were to try to submit
this again to an Elm conference, I would probably try to invert things. Instead
of discussing a big idea and giving some examples, I'd give a talk focused on a
single problem such as that synchronizable data example and weave in this idea
as part of the _why_ the solution works.
## Keep submitting
> A Number by Any Other Name
>
> In 1999 NASA’s Mars probe infamously crashed due to a unit of measure error.
> 20 years later we still write the same bug. Join me as we leverage Elm’s type
> system to catch these, get better errors, and improve readability. Along the
> way we’ll challenge some common assumptions we have around numbers.
>
> -- [Full proposal][A Number by Any Other Name]
Just because a conference rejects your talk doesn't mean it is bad! Maybe they
could only pick their top 10 out of 200 submissions and yours was number 11.
Maybe they received many proposals similar to yours and are trying to have more
variety. Maybe your idea doesn't quite fit with their audience.
Don't give up! It's totally OK to submit your proposal to **another
conference**, or even to the same conference next year. Don't just copy/paste
and mass-mail your idea to all the conferences though. Tweak your proposal to
best fit what each conference is looking for.
_A Number by Any Other Name_ was a talk I'd been wanting to give for quite a
while. I shopped it around many times before it got picked up by Elm in the
Spring 2019. I submitted it Elm Europe 2018 (they picked another of my
proposals), ElmConf 2018, and ElmConf 2019. Persistance paid off here!
## History
✅ = accepted, 🔁 = repeat submission
_There are several rejected talks to RailsConf, RubyConf, and some regional
Ruby conferences from before 2016 that are lost to the mists of time._
* **ElmConf 2016**
* ✅ [Rolling Random Romans]
* **Elm Europe 2017**
* [Mapping the World]
* [Solving Problems in Elm]
* [Making Impossible Functions Impossible]
* **ElmConf 2017**
* 🔁[Mapping the World]
* [Modeling Data with ADTs]
* **RailsConf 2018**
* [A Darwinian Nightmare]
* **Elm Europe 2018**
* [Why JSON Decoders?]
* [Real World JSON Decoding]
* [A Number by Any Other Name]
* ✅[Working with Maybe]
* **ElmConf 2018**
* [Data vs Metadata]
* [Domain-Specific Views in Elm]
* 🔁[Why JSON Decoders?]
* 🔁[Real World JSON Decoding]
* 🔁[A Number by Any Other Name]
* [Gamedev in Elm]
* **Elm in the Spring 2019**
* ✅🔁[A Number by Any Other Name]
* **RailsConf 2019**
* ✅[Beyond the Whiteboard Interview]
* Elm Europe 2019
* 🔁[Domain-Specific Views in Elm]
* ✅🔁[Gamedev in Elm]
* **ElmConf 2019**
* 🔁[Domain-Specific Views in Elm]
* 🔁[Real World JSON Decoding]
* [Refactoring in Elm]
[Rolling Random Romans]: https://gist.github.com/JoelQ/1f68d9c708d783823ea694d4a7d081be
[Mapping the World]: https://gist.github.com/JoelQ/6903d9136c9e82aa635d6ae4ac2bfcd3
[Solving Problems in Elm]: https://gist.github.com/JoelQ/bb010d28c571b6c74822976f7528293b
[Making Impossible Functions Impossible]: https://gist.github.com/JoelQ/5b98bee8ee46131dd96742034d345bab
[Modeling Data with ADTs]: https://gist.github.com/JoelQ/640414c3a95396d15a373d0405c427ad
[A Darwinian Nightmare]: https://gist.github.com/JoelQ/fe11721d2f17c4030d1f4a5b189c0660
[Why JSON Decoders?]: https://gist.github.com/JoelQ/176d570b7ce4a028bb00916c4794ac86
[Real World JSON Decoding]: https://gist.github.com/JoelQ/d64b0db11cd07e71030dd9b5e399fc6a
[Working with Maybe]: https://gist.github.com/JoelQ/1bb54e8f39374c92c41b47c7d6c4f459
[Data vs Metadata]: https://gist.github.com/JoelQ/5517905cfbfd1d79bb10b97e6d5dedf6
[Domain-Specific Views in Elm]: https://gist.github.com/JoelQ/85c0d59e7ad3d3efb7ba7c7d0387a3d8
[Gamedev in Elm]: https://gist.github.com/JoelQ/b01bfaa558bd3039221305518a2d5656
[A Number by Any Other Name]: https://gist.github.com/JoelQ/50a922c3614735483c119e019fd77382
[Beyond the Whiteboard Interview]: https://gist.github.com/JoelQ/4fda1bd8586637e959897410b1f08c4a
[Refactoring in Elm]: https://gist.github.com/JoelQ/01810cf7574f13a79e69f3d74d0d0500