Ringkasan eksekutif

Saya baru baca postingan JetBrains yang membuka Call for Papers KotlinConf 2027 di Kraków, tapi isinya bukan cuma pengumuman tanggal — mereka mengumpulkan saran dari panitia program dan pembicara lama tentang apa yang sebenarnya membuat proposal talk lolos review. Yang menarik buat saya, nasihatnya lebih ke arah "bagaimana reviewer membaca proposal Anda" daripada template generik soal public speaking.

Masalah yang coba diselesaikan

Banyak calon pembicara menahan diri karena mengira talk KotlinConf harus berisi temuan revolusioner atau sistem production berskala besar. Masalah lain yang disinggung: judul yang terlalu umum ("Our Multiplatform Journey"), abstrak yang cuma satu kalimat atau malah kepanjangan, dan takeaway yang kabur seperti "you will learn best practices" — semua ini membuat reviewer kesulitan menilai apakah talk itu layak diterima, bahkan kalau topiknya sebenarnya bagus.

Poin-poin utama dan contoh

Beberapa hal konkret yang saya catat dari para panelis:

  • Pengalaman sebelumnya tidak wajib. Marcin Mycek (PM, Kotlin Build Tools) bilang kalau Anda bisa menemukan dua orang di sekitar yang mau dengar topik itu lebih dari lima menit, itu sudah kandidat yang layak.
  • Reviewer menilai kerapian, bukan cuma ide. Pamela Hill-Galloway (Developer Advocate, panitia program) terang-terangan bilang abstrak yang terlalu pendek, terlalu panjang, atau "jelas-jelas hasil AI" membuat dia enggan memberi suara positif.
  • Judul harus informatif, bukan cuma catchy. Contoh perbandingan dari artikel: "Coroutines Gone Wild" (terlalu vague) vs "Debugging Coroutine Performance Problems in Production" (lebih jelas).
  • Struktur abstrak: context → challenge → approach → outcome. Márton Braun (Developer Advocate, panitia program) menyarankan dua-tiga paragraf, bukan satu kalimat atau skrip penuh.
  • Takeaway harus spesifik. Referensi nyata yang dikutip: talk Marcin Moskała "Taming Asynchronous Beasts: Debugging and Performance Tuning in a Coroutine World" menjanjikan peserta akan belajar "use built-in tools, recognize problematic patterns, and implement proven optimization strategies"; talk Tadeas Kriz "Dependencies and Kotlin/Native" menjanjikan penjelasan soal "how native dependencies interact, how they are loaded".
  • Koneksi ke Kotlin harus eksplisit, terutama untuk topik Android/Compose — Márton Braun mencontohkan bahwa materi Jetpack Compose sering lebih cocok diajukan lewat framing Compose Multiplatform.
  • Lightning talk itu pilihan sah kalau materinya tidak cukup untuk sesi penuh, dan satu orang boleh submit lebih dari satu proposal asal ceritanya benar-benar berbeda.

Artikelnya murni berisi saran menulis, tanpa kode. Supaya lebih kebayang, ini ilustrasi (bukan dari sumber) cara saya akan mem-breakdown ide talk jadi checklist sebelum submit:

# 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)"

Dampak dan catatan untuk calon pembicara

KotlinConf 2027 CFP sudah dibuka, dan artikel ini jelas ditujukan untuk menaikkan kualitas submission, bukan sekadar jumlahnya. Buat saya pribadi, poin yang paling actionable adalah uji "kalau Kotlin dihapus, apakah proposal ini masih utuh?" — itu filter yang bagus buat topik Android/Compose generik yang sebenarnya bukan cerita Kotlin. Catatan lain yang relevan: mereka secara eksplisit minta jangan submit abstrak hasil LLM mentahan (disebut oleh Márton Braun), jadi kalau pakai AI untuk bantu merapikan tata bahasa, tetap pastikan suara dan pengalaman aslinya yang tampil.

---

Pertama diumumkan di JetBrains Kotlin blog. Baca sumber aslinya untuk detail lengkap.

Baca juga