Executive summary
I just read a JetBrains post announcing the opening of the KotlinConf 2027 Call for Papers in Kraków, but the content isn't just a date announcement — they gathered advice from program committee members and past speakers about what actually makes a talk proposal pass review. What I found interesting is that the advice leans more toward "how reviewers read your proposal" than a generic public speaking template.
The problem it's trying to solve
Many prospective speakers hold back because they assume a KotlinConf talk has to contain revolutionary findings or a large-scale production system. Another problem raised: titles that are too generic ("Our Multiplatform Journey"), abstracts that are either just one sentence or way too long, and vague takeaways like "you will learn best practices" — all of this makes it hard for reviewers to judge whether a talk deserves to be accepted, even when the topic itself is actually good.
Key points and examples
A few concrete things I noted from the panelists:
- Prior experience is not required. Marcin Mycek (PM, Kotlin Build Tools) says that if you can find two people around you willing to listen to the topic for more than five minutes, that's already a viable candidate.
- Reviewers judge polish, not just the idea. Pamela Hill-Galloway (Developer Advocate, program committee) bluntly says that abstracts that are too short, too long, or "obviously AI-generated" make her reluctant to vote positively.
- Titles must be informative, not just catchy. A comparison example from the article: "Coroutines Gone Wild" (too vague) vs "Debugging Coroutine Performance Problems in Production" (clearer).
- Abstract structure: context → challenge → approach → outcome. Márton Braun (Developer Advocate, program committee) suggests two to three paragraphs, not a single sentence or a full script.
- Takeaways must be specific. A real reference cited: Marcin Moskała's talk "Taming Asynchronous Beasts: Debugging and Performance Tuning in a Coroutine World" promises attendees will learn to "use built-in tools, recognize problematic patterns, and implement proven optimization strategies"; Tadeas Kriz's talk "Dependencies and Kotlin/Native" promises an explanation of "how native dependencies interact, how they are loaded".
- The connection to Kotlin must be explicit, especially for Android/Compose topics — Márton Braun gives the example that Jetpack Compose material is often better submitted through a Compose Multiplatform framing.
- A lightning talk is a legitimate choice if the material isn't enough for a full session, and one person may submit more than one proposal as long as the stories are genuinely different.
The article is purely writing advice, with no code. To make it more concrete, here's an illustration (not from the source) of how I'd break down a talk idea into a checklist before submitting:
# ilustrasi: checklist cepat sebelum submit proposal KotlinConf
echo "Judul menjelaskan topik + masalah + manfaat? (y/n)"
echo "Abstrak punya context -> challenge -> approach -> outcome? (y/n)"
echo "Takeaway pakai kata kerja aksi, bukan 'belajar best practice'? (y/n)"
echo "Kalau kata 'Kotlin' dihapus, apakah cerita ini masih jalan? (y/n)"Impact and notes for prospective speakers
The KotlinConf 2027 CFP is now open, and this article is clearly aimed at raising the quality of submissions, not just their quantity. For me personally, the most actionable point is the test "if you removed Kotlin, would this proposal still hold together?" — that's a good filter for generic Android/Compose topics that aren't actually a Kotlin story. Another relevant note: they explicitly ask that you not submit raw LLM-generated abstracts (mentioned by Márton Braun), so if you use AI to help clean up grammar, make sure your own voice and experience still come through.
---
First announced on the JetBrains Kotlin blog. Read the original source for full details.