The Art of Writing a CFP

This article was originally published on bmf-tech.com.

Overview

Submitting a CFP (Call for Papers) for conferences and speaking events is a common practice. Here, I will write a poem about how I craft and submit my CFPs.

Past Achievements

I have submitted CFPs seven times in the past, with a 100% acceptance rate (though I declined one due to various reasons).

The events I have spoken at include PHP and Go conferences, with more appearances at PHP conferences.

cf. https://speakerdeck.com/bmf_san

To be honest, there were many shortcomings in my early presentations and CFPs, but recently I've gained a lot more confidence, so I thought I'd leave my thoughts here.

My Way of Writing a CFP

Before Writing a CFP...

I always organize what I do before writing a CFP.

Consider the Purpose of Speaking

What do I want to gain from speaking? Having this clear helps motivate me.

I focus on whether it seems valuable both for myself and the audience. While it's not wrong to think only about personal benefits and consider the CFP's acceptance as a validation of its value to the audience, considering various perspectives broadens the range of presentation themes and increases what I can gain.

Decide on the Event to Speak At

If it's an event I've attended before, I can easily imagine the atmosphere and themes. If not, it's better to research past events or actually attend them.

Knowing the themes, level of presentations, audience characteristics, and sponsor companies helps build confidence when speaking, making it an important preparation step.

Thanks to past experiences, I don't get nervous speaking in front of people; rather, I enjoy it. However, this prior research helps maintain my mental state.

Thoroughly Check the Event Schedule

It's obvious, but if the schedule doesn't match even if the CFP is accepted, it would be sad. It's best to adjust the schedule in advance.

How to Write a CFP

By the time I submit a CFP, I usually have a rough idea of the presentation.

When I start writing a CFP, I have a somewhat organized outline of the presentation theme and can almost start writing the slides.

It depends on the person, but for me, the "idea" comes first, and once I see "this idea can be presented," I consider speaking. (There might be cases where you create an idea from keywords and prepare for the presentation, similar to presentation-driven development.)

I'll explain the steps I take to submit a CFP.

Prepare the Idea

Nothing starts without an idea.

Sometimes I use things I've done privately based on interests as ideas, or I start by thinking of ideas related to specific technologies, but it's mostly the former.

Write a Blog

Writing a blog to submit a CFP might seem odd, but this process is crucial for me.

Writing a blog ≈ CFP written, slides almost done.

By writing a blog, I can expand the idea, making CFP writing and slide creation smoother.

It's important to write a blog with a proper structure, not just as a memo.

Write the CFP

My method is to write a blog before writing the CFP.

Instead of writing the CFP immediately, I organize various things.

Recently, I've been using Miro to organize.

I organize it like the image below.

Here's the format I prepare to write a CFP.

• Session Title
• Event Information
• CFP
• Acceptance Criteria
• What to Talk About / What Not to Talk About
• What I Want to Convey
• Keywords
• Outline
• Slide Draft
• Research

By completing this format in no particular order, the CFP is finished.

The original idea for this format was taught by a senior engineer at a company I used to work for, but I've added my own touches.

I'll explain each part of the format using the preparation content submitted for Go Conference 2021 as an example.

Session Title

Write the session title.

If the idea is ready and the blog is written, the session title can be mostly decided, but if not, I set a tentative title first.

When thinking about the title, I only consider whether it conveys the presentation's image concisely in one breath, similar to naming functions or variables when coding.

Event Information

Check and write down information about the event.

Write the event title, date, and details of the speaking slot for which you're submitting the CFP.

CFP

Write the text of the CFP to be submitted.

Sometimes I write it after organizing other parts, or I write a rough draft first.

I feel that CFPs have a certain character limit, but even if not, I try to write concisely.

As long as it includes the necessary information for the selectors, it should be fine to write it briefly.

I write the CFP with the following outline.

• What will be discussed
• Who is the target audience, and who would benefit from listening
• What information can be gained from the presentation
• Outline of the presentation content
• Supplementary material links

Acceptance Criteria

Check and write down the event's acceptance criteria.

Most conferences have acceptance criteria.

This is a regulation, so read and confirm it carefully.

Not only the acceptance criteria but also the code of conduct should be read thoroughly.

What to Talk About / What Not to Talk About

Write what to talk about and what not to talk about.

It's especially important to write what not to talk about. Prioritizing the main theme and avoiding talking too much about unrelated topics prevents the content from becoming scattered and hard to convey, so it's important to clarify unnecessary topics.

What I Want to Convey

Write what you want to convey.

You can write as many as you want, but focusing on one per theme makes the content more cohesive.

Keywords

Pick up and write keywords related to the presentation content.

This is more about organizing and finding key points rather than expanding ideas.

Writing them out helps identify important keywords, making it easier to summarize what you want to convey and assert.

Conversely, it also reveals keywords that may not need to be addressed, so I write them out as an exercise.

Outline

Write the outline of the presentation content.

I sometimes write this, sometimes not. If the blog is finished, I might not write it; if not, I write it to prepare the blog.

If the blog is finished, I organize the outline based on the blog content.

Slide Draft

Write a rough image of the slides using sticky notes.

This is about imagining how to translate the outline into slides, but recently I've been using slide creation software to create outlines as sticky notes and make slides, so it might not be necessary. However, doing it helps you be aware of the presentation flow, notice any inconsistencies, and identify areas that need more depth, so it's worth doing.

Research

Write down anything you want to research thoroughly or delve into later.

Summarize and memo research items like preparing sample implementations or conducting technical verifications.

Also, write down checks for logical or factual confirmations of what you want to assert.

CFP Examples

Here are examples of CFPs I have actually submitted.

Go Conference 2021/Introduction to Building an HTTP Router with net/http

I will talk about how to build an HTTP router using Go's standard package net/http. Starting with reading the code to launch a simple server using net/http, I will explain how to build an HTTP router and the algorithms involved. Although there may not be many opportunities to build one from scratch due to the existence of excellent routers as OSS, I believe building one can deepen your understanding of net/http and tree structures. This LT targets Go beginners.

Here are the main materials for this LT.

## Github
- [github.com - bmf-san/goblin](https://github.com/bmf-san/goblin)

## Blog
- [Golang's HTTP Server Code Reading](https://bmf-tech.com/posts/Golang%E3%81%AEHTTP%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0)
- [Introduction to Building URL Routing from Scratch Episode 1](https://bmf-tech.com/posts/URL%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E8%87%AA%E4%BD%9C%E5%85%A5%E9%96%80%E3%80%80%E3%82%A8%E3%83%94%E3%82%BD%E3%83%BC%E3%83%89%EF%BC%91)
- [Introduction to Building URL Routing from Scratch Episode 2](https://bmf-tech.com/posts/URL%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E8%87%AA%E4%BD%9C%E5%85%A5%E9%96%80%E3%80%80%E3%82%A8%E3%83%94%E3%82%BD%E3%83%BC%E3%83%89%EF%BC%92)
- [Introduction to URL router from scratch with Golang](https://dev.to/bmf_san/introduction-to-url-router-from-scratch-with-golang-3p8j)


## Slides
- [Built a URL Router with Golang](https://speakerdeck.com/bmf_san/golangteurlrutawotukututa)

Go Conference 2023/The Ultimate HTTP Router Dance

This was accepted, but I had to decline due to unavoidable circumstances. I really wanted to participate, and I feel regret and apologize to the organizers. This idea is still an unpublished work, so I plan to try again next time.

Go provides a standard feature (multiplexer) for routing, but in actual development, you often use some HTTP Router package.

I have been building my own HTTP Router, and I wanted to compare its performance with existing packages.

So, I implemented a benchmarker and worked on comparing performance differences.

I will talk about the results of picking up and comparing several packages and the learnings from it.

This LT will consider the following outline.

Motivation
Premises (premises for performance comparison)
Measurement methods and targets
Measurement results
Learnings

I want to provide my answers to questions like "Which HTTP Router performed the best? (according to me)", "What is the performance difference with the standard multiplexer?", and "Can performance alone be a criterion for selecting an HTTP Router?"

// The following is not the main body of the CFP but a supplementary text submitted
This presentation is based on a past presentation, "The Ultimate HTTP Router Martial Arts Tournament."

cf. https://speakerdeck.com/bmf_san/tian-xia-httprouterwu-dou-hui

I plan to organize and brush up on parts that were not fully organized in the initial content of that presentation and make it the theme of this presentation.

I changed it to a dance because martial arts tournaments sound violent, and martial arts tournament 2 sounds mysterious.

Other related information
https://dev.to/bmf_san/implemented-a-bench-marker-to-compare-gos-http-router-146p
An article summarizing the comparison of HTTP Routers
https://github.com/bmf-san/goblin
My self-made HTTP Router

As a hidden theme, I hope to convey the fun of implementing an HTTP Router to the audience.

Conclusion

The key point or tip for me when writing a CFP is "to have a blog written."

If you can output in writing, about 60-70% of the presentation preparation is done.

When I usually finish a CFP, I write it in this flow, but as I repeat the process, the method becomes rougher, but I make sure not to skip the task of writing a blog.

Once the CFP is accepted, it's just a matter of riding the flow to create and refine the slides, so you can proceed smoothly.

Although it's somewhat formal, I think that by not neglecting preparation, the work becomes smoother, and the acceptance rate increases (personal opinion).

Speaking of which, I once served as a selector for an event as an organizer, and I think it's important to put yourself in the selector's shoes.

Thoughts

I always think there's room to study these business skills, but due to laziness, I haven't been able to...

Since impressions can be influenced by how you convey things, I believe the return on honing these skills is significant, but recently I have a feeling that ChatGPT might become a good teacher.

Aside

I intended to limit the discussion to CFPs, but I'll add an aside.

Things to Keep in Mind When Creating Slides

I've organized a few things I keep in mind when creating slides for speaking events.

• First, finish roughly, move your hands first, and refine details gradually. Like agile.
  • If you try to complete each slide, you might fall into the waterfall trap.
  • You often end up reworking, losing sight of the overall picture, and the flow of the slides becomes inconsistent.
• Don't put too much text.
  • I think presentation materials are like that.
  • Even if you write a lot of text, the audience can't read it all, and they come to listen to the talk.
• Practice
  • Measure time, practice in the same environment as the actual presentation (match the device, presentation method, etc.).
  • Properly operate slide transitions, check if speaker notes are visible if you split the screen, etc.
  • If you fumble during the actual presentation, you'll waste time...
  • It's also good to roughly check how many seconds you can spend per slide.
• Keep the volume modest.
  • For a 15-minute presentation, it's just right to narrow down the slide count and content to something that can be covered in about 12-13 minutes.
  • Even if you're not nervous, if there are various things you want to talk about, the talk tends to extend (which can also be due to lack of practice).
• Don't write too much in speaker notes.
  • Don't make notes that can be read aloud as they are.
  • Unless you're an announcer, it tends to become monotone.
• Think about the words to use at transitions in the talk.
  • In the flow of the talk, there are scenes where the topic changes, and I often struggle with how to smoothly move to the next topic, so I choose words in advance.
  • If you can't find good words, there might be room for improvement in the flow of the talk, so refactor it.
• Keep the self-introduction slide simple.
  • Unless there's a case where you should write it properly depending on the purpose of the presentation or event, keep it brief.
  • There's a strategic way of writing it as a conversation starter for after-parties, but it's a low priority that can be considered after all slides are finished.
• Don't include easy jokes or gags.
  • In official talks, don't include unnecessary "gags." There's no need to take risks that don't match the cost.
  • Also avoid quirky metaphors...
• Get a review
  • As an individual activity, I often complete it on my own, but if it's part of work, it's good to get feedback from others through a review.