CFP typically stands for “Call for Papers”.

I don’t know that I have a ton of advice for submitting proposals. I think my actual success rate is probably 50%. But I’ll try to distill what I think has worked for me.

Picking a topic

First things first you’ll want to pick a topic that has a chance of getting accepted. Keep in mind that the people picking your talk are going to pick talks that will help them sell tickets and build an interesting conference. Think about that audience and talks that will have a good chance of appealing to selectors. Go look at the previous years and see what sorts of talks that they select (every conference has trends and show clear biases). Quite frankly, its much easier to get a “safe” topic accepted then it is to get something more novel accepted. For example a talk that shows how to build something with LiveView is more likely to be accepted than a talk about an alternative to LiveView. Getting a talk accepted about something no one is talking about yet is much harder to do. I personally submitted multiple talks on property based testing for years and they never got accepted. When I eventually did give a talk on property based testing I had to petition the organizer to let me do it. Then the elixir community got really excited about property based testing and at the next elixirconf there was something like 3 talks on the subject. Thats just how it goes sometimes. Not all conferences are like this but most elixir confs. are. And like I said, they all have their biases.

You can sometimes skirt these rules by either 1) having a name that the selection committee will recognize or 2) Framing your submission in terms that the selection committee will relate with and get excited about. For instance I submitted a talk on Raft at one point and iirc I never used the words “raft” in the submission. I tried to frame the entire talk in terms of distributed erlang and other terms that the selection committee would understand.

Writing the submission

When it comes to writing the actual proposal I’ve found that its best to have about 2-3 short paragraphs describing your talk. Each of my submissions follows the same basic pattern:

1. Establish common ground
2. Establish the problem
3. Explain how your talk is going to present the solution.

You want to give some concrete takeaways here so that the audience understands what they’re going to get out of the talk. Let’s say I wanted to give a talk on LiveView. Here’s a really short example:

“”"
Modern web applications are requiring more and more interactivity. But keeping up with the ever changing Javascript landscape is exhausting. We need better ways of building interactive, immersive client side experiences without sacrificing productivity.

In this talk we’ll see how LiveView allows us to build rich client side experiences without having to leave the comfort of elixir. The audience will leave with a deep understanding of LiveView fundamentals and the most common pitfalls.
“”"

Tips on submitting

When you fill out your submission there will typically be a section called like, “Notes to the organizers”. FILL THIS OUT!!! I can’t even tell you how many new speakers don’t put anything in here. This is your chance to sell the organizers on why you should be the one to speak on this topic. Explain to them why you’re experience and knowledge are why you should be selected. Link to your open source libraries or blog posts. If you’ve spoken at meetups or other conferences than say that (and provide links to videos if they’re available). It feels gross to sorta shamelessly promote yourself. Unfortunately that’s part of the game.

If you want to increase your odds of getting accepted then you should also submit more than one talk. This is a thing that a lot of new speakers don’t know. Conference organizers expect to get multiple submissions from people. Typically 2 or 3 is the appropriate amount if it’s a conference that you really want to speak at.

Thats all I can think of off the top of my head. I hope it goes well for you!

For the past few years I’ve been involved in the process of rating the proposals for a local event. Based on that experience, my number 1 tip would be to invest time to make your proposal concise and to the point. The proposal shouldn’t be too long, but also not too short. It should provide a clear idea of what you’re planning on covering in the talk.

By making a clear proposal, you’re demonstrating your ability to explain a topic. Think of proposal itself as a small explanation. As a reviewer, if I see a proposal which is not well formulated, I’m starting to wonder whether the talk itself will be understandable. My rating of the proposal reflects my doubt

Another thing I personally dislike is when a speaker submits a lot of proposals. 1-2 proposals per speaker is great, 3 or 4 is fine I guess, but going beyond that makes me wonder if the candidate is trying to get the slot at any cost, preferring quantity over quality. So my suggestion is to pick one or two topics which you think people visiting the conference might enjoy, and focus on making good proposals out of those topics. If you already have a stash of prepared proposals from earlier conferences, pick 1-3 which you think would be a good fit for the conference.

When it comes to technical topics, I personally prefer talks which are based on the speaker’s own experience, along the lines of “we had this problem, and here’s how we solved it”. It’s not a deal breaker, and it doesn’t completely influence the rating, but it might serve as an extra bonus. As an example, when I submitted my first proposal for a talk about Erlang, I named it “Erlang in practice”, and I stressed in the abstract that the talk is based on our own production experience with Erlang. I feel that this improved my chances of being accepted.

If it helps, you can check the Talk committee guidelines for the WebCamp Zagreb conference. Of course, bare in mind that different committees have different ways of thinking, and use different selection processes.

In summary, pick a good topic. Asking yourself the question “If I didn’t know about this thing, would I find the talk interesting?” is a good test. Once you have the topic, focus on making a good and understandable abstract. After you submit, hope for the best, but don’t take it too hard if you don’t get accepted. Conferences typically receive much more submissions then they have available slots (for WebCamp Zagreb it’s about 5x-10x), so rejections are something all of us experience from time to time. If you feel your proposal is good, look for other events where you can submit it. Also, IMO it’s perfectly fine to submit the same proposal for the same event again next year.

Wish you best of luck!

Great advice above, and I’ll add one other dimension to consider. Most user groups are happy to have first time presenters. They tend to be lower-stress and smaller audiences that you can get some honest feedback from afterward on your presentation skills. This sort of experience would be a positive thing for reviewers to see in your notes to the organizers. It will also help you gain confidence that you have something to start with that just needs some tweaks before giving the talk at a major conference.

Thank you for responding @keathley and for sharing your experience

I almost did just that but thought: I better ask before submitting

This is a great point

I didn’t know this either I would have thought I was been annoying if I tried submitting several talks

This makes complete sense

I can see why that is, the closer to reality the content is the better the talk will be

It is helpful to sort of know what happens on the other side

That’s good to know to keep expectations = reality

Agreed, I will try to do that as well to gain experience

Thank you for taking the time to answer @sasajuric @gregvaughn