Что делает заявку на KotlinConf отличной?

Лаконичный мультиплатформенный язык, разработанный JetBrains

Kotlin KotlinConf

Открыт прием заявок на конференцию KotlinConf 2027! Мы приглашаем разработчиков со всего сообщества Kotlin представить свои идеи, опыт и экспертизу на сцене в Кракове.

У вас есть урок или открытие, связанное с Kotlin, которое могло бы помочь другим разработчикам? Возможно, вы решили сложную техническую задачу, внедрили Kotlin в существующую кодовую базу, создали что-то неожиданное или извлекли ценные уроки из подхода, который пошел не по плану.

Этот опыт может стать докладом на KotlinConf.

Подать заявку

Однако превратить идею в убедительную заявку на конференцию бывает непросто, особенно если вы никогда раньше их не подавали. Как понять, стоит ли ваш опыт того, чтобы им делиться? На что рецензенты обращают внимание в первую очередь? Насколько подробным должен быть ваш тезис? И как сделать так, чтобы знакомая тема выделялась?

Чтобы помочь вам подготовить заявку, мы спросили разработчиков на Kotlin, адвокатов бренда (developer advocates), опытных спикеров и членов программного комитета KotlinConf, что делает заявку сильной. Помимо практических советов по составлению названия, тезисов и выводов, мы добавили новый раздел, отвечающий на особенно важный вопрос: на что рецензенты обращают внимание в первую очередь, когда открывают заявку?

Вы выступаете впервые? Все равно подайте свою идею!

Легко предположить, что доклад на KotlinConf должен начинаться с революционного открытия, крупной производственной системы или многолетнего опыта выступлений. На самом деле ценный доклад может начаться с простой идеи или урока, извлеченного при решении повседневной задачи разработки.

Вам не нужно знать о Kotlin absolutamente все — вам нужна полезная идея, которой стоит поделиться, и четкое понимание того, кому она может помочь.

Памела Хилл-Галлоуэй (Pamela Hill-Galloway). Developer Advocate, член программного комитета KotlinConf и спикер KotlinConf

X, BlueSky, LinkedIn

Все равно подайте свою идею! На KotlinConf было немало оглушительно успешных докладов, которые начинались всего лишь с простой идеи.

Если вы не уверены, заинтересует ли кого-то ваша тема, обсудите ее с окружающими. Объясните идею коллегам, друзьям, участникам группы пользователей или людям из сообщества Kotlin. Их вопросы и реакции помогут вам понять, какие части представляют наибольшую ценность.

Марцин Мыцек (Marcin Mycek). Менеджер по продукту, Kotlin Build Tools

LinkedIn

Если вы сможете найти хотя бы одного заинтересованного человека, скорее всего, их будет больше! Если вы найдете вокруг себя как минимум двух людей, которым тема покажется интересной и которые смогут слушать больше пяти минут, это уже вполне подходящий кандидат.

Предыдущий опыт выступлений на конференциях не требуется. Четкая, аутентичная заявка, основанная на том, что вы понимаете и о чем заботитесь, может быть более убедительной, чем вылизанный текст без особого содержания.

Начните с истории, которую хотите рассказать

Прежде чем писать название или открывать форму заявки, определите центральную историю, лежащую в основе вашего доклада.

«Доклад о корутинах» или «сессия о Kotlin Multiplatform» описывают предметную область, но не объясняют, в чем ценность выступления.

Задайте себе вопросы:

• С какой проблемой, вопросом или возможностью вы столкнулись?
• Почему это было важно или сложно?
• Что вы попробовали сделать?
• Что вас удивило?
• Что удалось, а что нет?
• Что вы узнали такого, что другие разработчики могли бы применить на практике?

Ваша история не обязательно должна быть связана с крупной компанией или системой, которой пользуются миллионы людей. Сфокусированный урок из небольшого проекта может быть не менее полезным, если он предлагает оригинальный взгляд или понятно объясняет сложную тему.

Попробуйте сформулировать идею в одно предложение, например:

Этот доклад покажет [аудитории], как мы [решили или исследовали что-то], чему мы научились и как они могут применить эти уроки на практике.

Если вы не можете четко завершить это предложение, возможно, идею стоит немного доработать, прежде чем приступать к написанию заявки.

На что рецензенты обращают внимание в первую очередь?

Название может быть первой строкой, которую читают рецензенты, но общий уровень проработки становится заметен очень быстро.

Рецензенты оценивают не только то, насколько интересна тема, но и может ли спикер понятно ее объяснить. Продуманное название, сфокусированное описание, конкретные выводы и аккуратное оформление показывают, что вы потратили время на развитие своей идеи.

Памела Хилл-Галлоуэй (Pamela Hill-Galloway). Developer Advocate, член программного комитета KotlinConf и спикер KotlinConf

X, , LinkedIn

Я могу подытожить это так: внимание, которое вы уделяете написанию заявки, пожалуй, более очевидно, чем люди думают. Если я вижу, что вы потратили время на то, чтобы придумать броское или описательное название, которое хорошо сочетается с содержанием, мне гораздо проще поставить вам палец вверх для выступления на KotlinConf. Если ваше описание настолько короткое, или длинное, или настолько явно сгенерировано ИИ, что вы не можете четко и аккуратно выразить свою идею, я, скорее всего, не проголосую за ваш доклад.

Это не значит, что вам нужно использовать сложный язык или создавать идеальный маркетинговый питч. Это значит, что нужно дать рецензентам достаточно информации для понимания вашей идеи и показать, что заявка отражает ваш собственный опыт и голос.

Доклад Марцина Москалы (Marcin Moskała) «Укрощение асинхронных зверей: отладка и тюнинг производительности в мире корутин» служит хорошим примером четкого обещания: «Вы узнаете, как эффективно использовать встроенные инструменты, распознавать проблемные паттерны и применять проверенные стратегии оптимизации».

Напишите четкое и информативное название

Сильное название должно дать рецензентам, а впоследствии и слушателям, точное представление о том, чему будет посвящен доклад.

Креативность может сделать название запоминающимся, но на первом месте должна стоять ясность. Избегайте названий, которые целиком строятся на шутке, отсылке или метафоре без объяснения сути темы.

Памела Хилл-Галлоуэй (Pamela Hill-Galloway). Developer Advocate, член программного комитета KotlinConf и спикер KotlinConf

X, , LinkedIn

Тщательно подобранное название может решить все! У зрителей часто нет времени или концентрации читать что-то длиннее названия, когда они решают, идти ли на доклад. Предпочтите ясность броскому или веселому названию, которое в двух словах не дает хорошего представления о том, чему посвящено выступление.

Сравните следующие примеры названий:

Слишком широкое:Наш мультиплатформенный путь

Более информативное:Чему мы научились при миграции нашего мобильного приложения на Kotlin Multiplatform

Слишком туманное:Корутины во все тяжкие

Более информативное:Отладка проблем с производительностью корутин в продакшене

Слишком общее:Создание лучших API

Более информативное:Проектирование типобезопасных API на Kotlin, которые сложно использовать неправильно

Хорошее название обычно отражает как минимум два пункта из следующего списка:

• Основная тема
• Проблема или вопрос
• Контекст, в котором она исследовалась
• Практическая польза для слушателей
• Ожидаемый уровень подготовки

Вы по-прежнему можете использовать юмор или игру слов, но убедитесь, что название не скрывает того, чему на самом деле посвящено выступление.

Стройте тезисы вокруг четкого повествования

Ваши тезисы не должны содержать всю вашу презентацию. Тем не менее, они должны предоставлять достаточно деталей, чтобы рецензенты поняли проблему, направление доклада и его ценность.

Обычно два или три сфокусированных абзаца доносят мысль лучше, чем одно расплывчатое предложение или очень длинное описание, охватывающее каждую деталь.

Себастьян Селлмайр (Sebastian Sellmair). Разработчик ПО и спикер KotlinConf

X, BlueSky, YouTube

Выступление на KotlinConf — это прекрасный опыт и огромное достижение для любого Kotlin-разработчика. Хотя выбор отличного названия, наличие тщательно проработанных анимаций и подборка качественных мемов могут улучшить ваш доклад, самое главное — это история, которую стоит рассказать. Есть ли у вас что-то новое и технически интересное для презентации? Можете ли вы разобрать тему увлекательно и по-настоящему весело? Можете ли вы вдохновить других разработчиков?

Мартон Браун (Márton Braun). Developer Advocate, член программного комитета KotlinConf и спикер KotlinConf

X, BlueSky, LinkedIn

Хотя нам не нужен полный сценарий вашего выступления в качестве аннотации, мы вряд ли примем доклад, аннотация которого состоит всего из одного предложения. Два или три абзаца обычно достаточны для передачи содержательных деталей.

Простая структура может помочь:

Контекст

Представьте ситуацию и аудиторию, которая, вероятно, сможет ее узнать.

Проблема

Объясните проблему, ограничение или вопрос, которые побудили к работе.

Джоди Бёрчелл (Jodie Burchell). Developer Advocate и специалист по работе с данными

LinkedIn, Mastodon, BlueSky

Зацепите аудиторию, рассказав о проблеме, которую вы собираетесь решить. Люди любят детективные романы не просто так: в них создается определенное напряжение перед тем, как перейти к разгадке. Отличная заявка делает то же самое.

Подход

Опишите то, что вы исследовали, внедрили, сравнили или обнаружили.

Результат

Уточните, чему научатся участники и как они смогут это применить.

Сильный практический вывод может быть столь же конкретным, как и в докладе Тадеаша Криза (Tadeas Kriz) «Зависимости и Kotlin/Native»: «Узнайте, как взаимодействуют нативные зависимости, как они загружаются, и с какими неожиданными сложностями сталкивается нативный мир».

Шанталь Лонкль (Chantal Loncle). Разработчик ПО, Exposed, JetBrains

LinkedIn

Избегайте расплывчатых обещаний. Вместо этого используйте глаголы действия и конкретные результаты, чтобы описать точные возможности и изменения, которые получит аудитория. Уйдут ли они с вашего доклада с чувством, что время было потрачено не зря? Если да, то какие практические знания, мгновенно применимые навыки или ценные инструменты они унесут с собой?

Например:

Поддержание раздельных реализаций для Android и iOS позволяло нашим командам двигаться независимо, но также приводило к дублированию бизнес-логики и несогласованному поведению между приложениями.

В этой сессии мы рассмотрим, как мы внедряли Kotlin Multiplatform постепенно, начав с одной общей функции вместо попытки полной миграции. Мы обсудим, как мы выбирали первый компонент, структурировали общий код, тестировали его на разных платформах и работали с существующими нативными приложениями.

Вы уйдете с практическим фреймворком для оценки того, где внедрять общий код, каких трудностей ожидать и как планировать инкрементальное внедрение Kotlin Multiplatform без переписывания всего приложения.

Этот пример обозначает проблему, объясняет, чему будет посвящена сессия, и дает аудитории причину прийти. Он не раскрывает каждую деталь, но дает конкретное обещание.

Думайте как участник

Сильная заявка не сосредоточена только на том, что спикер хочет представить. В ней также объясняется, что получит аудитория.

Спросите себя:

• Для кого эта сессия?
• какими знаниями уже должны обладать участники?
• Какую проблему поможет решить этот доклад?
• Что они поймут или смогут сделать после него?
• Почему они должны выбрать именно эту сессию среди других докладов, проходящих в то же время?

Светлана Исакова. Тимлид команды продвижения Kotlin, член программного комитета KotlinConf и спикер KotlinConf

Подавая доклад, думайте как участник. Захотели бы вы сами слушать это? Что это дает аудитории? Именно поэтому мы спрашиваем об основных выводах. Чему вы хотите научить людей, что они смогут попробовать, сделать или чем вдохновиться?

Избегайте общих обещаний вроде:

• «Вы узнаете лучшие практики».
• «Мы рассмотрим Kotlin Multiplatform».
• «Этот доклад охватит корутины».

Вместо этого описывайте конкретные результаты:

• Участники узнают, как выявлять и отлаживать три частые проблемы производительности корутин.
• Участники поймут, как мы структурировали общий код для Android и iOS.
• Участники смогут оценить, подходит ли этот подход для их собственного проекта.
• Участники узнают, какие части нашей миграции сработали, какие нет и что мы бы изменили сегодня.

Конкретные выводы делают заявку проще для оценки. Если доклад будет выбран, они также помогут участникам решить, актуален ли он для них.

Сделайте знакомую тему свежей

Ваша тема не обязательно должна быть абсолютно новой. Многие ценные конференционные доклады рассматривают устоявшиеся технологии с перспектив, которые раньше не изучались подобным образом.

Если вы предлагаете популярную тему, определите, что делает вашу версию особенной. Это может быть:

• Реальный кейс из продакшена
• Необычный масштаб или окружение
• Удивительный результат
• Неудачный подход и то, чему он вас научил
• Сравнение нескольких возможных решений
• Постепенная миграция вместо реализации с нуля
• Нетрадиционное использование Kotlin
• Личный опыт, который ставит под сомнение общепринятое предположение
• Особенно ясный способ объяснения сложной концепции

Например, «Введение в Kotlin Multiplatform» звучит широко и привычно. А «Что сломалось, когда мы внедрили Kotlin Multiplatform в семилетнее мобильное приложение» задает конкретный контекст и вызывает любопытство.

Будьте честны насчет компромиссов. Доклад не обязательно должен представлять собой историю безуспешного успеха. Рассказ о том, что потерпело неудачу, что изменилось и что вы сделали бы иначе, может оказаться особенно полезным для других разработчиков.

Шанталь Лонкль (Chantal Loncle). Разработчик ПО, Exposed, JetBrains

LinkedIn

Внесение реального, практического повествования в знакомую тему может укрепить заявку. Будьте честны в том, что сломалось, что расстроило вашу команду или что вы сделали бы иначе, если бы могли повернуть время вспять. Знакомая проблема может зазвучать по-новому, если посмотреть на нее глазами человека, который завтра впервые столкнется с тем же самым.

Вместо того чтобы давать очередной общий обзор, постройте доклад вокруг одной конкретной болевой точки или открытия и вводите более широкие темы только там, где они поддерживают эту историю. Вывод, который участники смогут немедленно применить в своей работе, также поможет отличить заявку от базового учебного материала.

Сделайте заявку актуальной для KotlinConf

KotlinConf приветствует доклады о бэкенд-разработке, Android, мультиплатформенной разработке, веб, десктоп, ИИ, дизайне языков, инструментах, библиотеках, опыте разработчиков и других частях экосистемы Kotlin.

Какова бы ни была ваша сфера, роль Kotlin в этой истории должна быть очевидна.

Мартон Браун (Márton Braun). Developer Advocate, член программного комитета KotlinConf и спикер KotlinConf

X, , LinkedIn

Имейте в виду, что ваш доклад должен быть связан с Kotlin! Например, далеко не каждый доклад об Android хорошо подходит для аудитории KotlinConf. Или доклады о Jetpack Compose часто затрагивают вещи, которые работают абсолютно так же и в Compose Multiplatform, причем последний гораздо с большей вероятностью будет принят на KotlinConf!

Тема про Android, например, далеко не автоматически становится темой для KotlinConf. Заявка становится более актуальной, когда в ней объясняется, как именно Kotlin повлиял на решение, рассматривается специфичное для Kotlin техническое решение или приводятся выводы, которые разработчики на Kotlin могут применить на практике.

Спросите себя:

• Почему это история именно про Kotlin?
• Какие аспекты опыта особенно важны для разработчиков на Kotlin?
• Осталась бы суть заявки прежней, если бы из нее убрали Kotlin?

Если ответ на последний вопрос утвердительный, укрепите связь с Kotlin перед отправкой.

Доклад Аншики Кул (Anshika Koul) «Великолепие кроссплатформенности Kotlin в Национальной почтовой службе Норвегии с 377-летней историей» (Kotlin Multiplatform’s Cross-Platform Brilliance at Norway’s 377-Year-Old National Postal Service) служит ярким примером ключевой мысли, сосредоточенной вокруг Kotlin: «Мы узнаем, как KMP предоставляет единую структуру для совместного использования кода и его выполнения на различных платформах, помогая решать проблемы с разными кодовыми базами под разные среды выполнения».

Звучите уверенно, но оставайтесь собой

Ваша заявка должна показывать, что вы понимаете, чем хотите поделиться и почему это важно.

Это не значит, что нужно преувеличивать свою экспертность или притворяться, будто у вас нет никаких сомнений. Это значит преподносить идею как четкое утверждение, а не подвергать ее ценность сомнению снова и снова.

Марцин Мыцек (Marcin Mycek). Менеджер по продукту Kotlin Build Tools

LinkedIn

Формулируйте утверждения как утверждения, а вопросы как вопросы. Сомневаться в себе — это нормально; все сомневаются, но распространенная ошибка — позволять этому проступать в тексте, например, превращая утверждения в вопросы. Перечитайте свою заявку или, что еще лучше, попросите кого-нибудь другого прочитать ее и задайте себе вопрос: производит ли этот человек впечатление убежденного в том, о чем он хочет рассказать?

Например:

Неуверенно:Может ли Kotlin Multiplatform помочь командам сократить дублирование бизнес-логики? В этом докладе мы, возможно, это выясним.

Увереннее:В этом докладе я покажу, как наша команда использовала Kotlin Multiplatform для сокращения дублирования бизнес-логики, в том числе где совместное использование кода помогло, а где нет.

Уверенность не должна стирать вашу индивидуальность. Заявка все равно должна звучать так, будто ее написали вы.

Марцин Мыцек (Marcin Mycek). Менеджер по продукту Kotlin Build Tools

LinkedIn

Оставайтесь собой! Важно убедиться, что ваша заявка понятна окружающим. Отличная практика — дать почитать ее нескольким людям, которым вы доверяете, и спросить, что они из нее поняли и какие чувства она у них вызвала. Тем не менее, сохраняйте в ней свою душу. Многие отличные доклады отличаются эксцентричностью, не следуют каждой лучшей практике, и люди приходят именно ради этого.

Советы и шаблоны могут помочь вам упорядочить мысли, но они не должны делать каждую заявку одинаковой. Ваша точка зрения, язык, юмор и энтузиазм — это часть того, что делает заявку запоминающейся.

Покажите рецензентам, как вы общаетесь

Примеры ваших прошлых докладов помогают рецензентам понять ваш стиль презентации и энергетику. Если у вас есть записи с конференций, митапов, вебинаров или прямых трансляций, приложите самые подходящие из них.

Если вы выступаете впервые и у вас нет профессиональной записи, вы можете записать себя на видео, объясняя часть предполагаемого доклада. Достаточно простой записи на ноутбуке. Здесь не нужны профессиональное освещение, монтаж или продакшн.

Светлана Исакова. Тимлид команды Kotlin Developer Advocacy, член программного комитета KotlinConf и докладчик на KotlinConf

Примеры ваших докладов помогают нам сделать лучший выбор. Если вы выступаете впервые и у вас нет записей, не переживайте! Вы можете просто записать себя (хотя бы часть предполагаемого доклада) на ноутбук и поделиться ссылкой. Мы будем вам очень признательны.

В зависимости от темы вы также можете приложить:

• Техническую статью
• Проект с открытым исходным кодом
• Написанную вами документацию
• Короткую техническую демонстрацию
• Участие в подкасте или митапе
• Другие работы, связанные с предполагаемым выступлением

Эти материалы подкрепляют вашу заявку, но они не заменяют четкое название, тезисы и ключевые выводы. Рецензенты должны иметь возможность понять суть выступления по самому тексту заявки.

Выберите формат, который подходит вашей идее

Далеко не каждая тема требует полноценного доклада.

Сфокусированный урок, эксперимент, сторонний проект или неожиданное открытие могут лучше сработать в формате молниеносного доклада (lightning talk). Тема, требующая значительного технического контекста, нескольких связанных выводов или подробной демонстрации, может потребовать обычного выступления.

Выбирайте формат в зависимости от объема содержательного материала, которым вы располагаете. Если вам приходится повторяться или добавлять ненужный контент, чтобы заполнить время обычного доклада, подумайте о том, чтобы вместо этого предложить молниеносное выступление.

Мартон Браун (Márton Braun). Developer Advocate, член программного комитета KotlinConf и докладчик на KotlinConf

X, , LinkedIn

Не забывайте, что мы также принимаем молниеносные доклады! Если вам кажется, что ваш контент придется искусственно раздувать, чтобы заполнить стандартное время выступления, в формате lightning talk он может смотреться намного выигрышнее.

Вы также можете отправить более одной заявки, если у вас есть несколько различных идей. Каждая заявка должна иметь собственную историю, целевую аудиторию и практические выводы, а не быть незначительной вариацией другой идеи.

Памела Хилл-Галлоуэй (Pamela Hill-Galloway). Developer Advocate, член программного комитета KotlinConf и докладчик на KotlinConf

X, , LinkedIn

Подавайте заявки на несколько докладов! Это дает вам больше шансов присоединиться к веселью на KotlinConf.

Проверьте заявку перед отправкой

Как только вы закончите черновик, отложите его на время и вернитесь позже, взглянув на него глазами человека, который сталкивается с этой идеей впервые.

Проверьте, отвечает ли ваша заявка на следующие вопросы:

• Понятна ли тема из названия?
• Является ли связь с Kotlin очевидной?
• Определены ли в тезисах реальная проблема, вопрос или история?
• Понятно ли, для кого предназначено это выступление?
• Являются ли выводы конкретными?
• Объясняет ли заявка, чем отличается ваша точка зрения?
• Реалистичен ли масштаб для выбранного формата?
• Звучит ли текст уверенно и аутентично?
• Проверили ли вы орфографию, грамматику, ссылки и форматирование?
• Звучит ли заявка так, будто ее написал человек, который будет читать этот доклад?

Попросите кого-нибудь другого также проверить ее. Вместо того чтобы просто спрашивать, нравится ли им текст, попросите их описать, о чем, по их мнению, будет доклад и что они ожидают из него узнать. Их ответ покажет, передает ли заявка именно то, что вы задумывали.

Шанталь Лонкль (Chantal Loncle). Разработчик ПО, Exposed, JetBrains

LinkedIn

Дважды проверьте, соответствует ли уровень предполагаемой аудитории описанию и ожидаемым выводам. Оцените заявку с точки зрения человека, которого вы надеетесь увидеть среди слушателей. Имеет ли она смысл в таком виде, в каком есть, или в ней не хватает контекста, который может быть очевиден вам, но не рецензенту или будущим зрителям, о которых вы помните?

Инструменты ИИ могут помочь вам проверить грамматику или упорядочить мысли, но итоговое предложение должно отражать ваш собственный опыт, идеи и индивидуальный стиль. Отретушированная аннотация без конкретных или подлинных инсайтов окажется менее убедительной, чем та, которая четко представляет выступающего.

Мартон Браун (Márton Braun), адвокат разработчиков, член комитетов программ KotlinConf и спикер KotlinConf

X, , LinkedIn

Ваша заявка должна показывать, что вы вложили определенные усилия идумали над ее подготовкой. Проверьте заявку на наличие проблем с форматированием и опечаток и, пожалуйста, не отправляйте аннотации, сгенерированные с помощью LLM.

Ваша история о Kotlin может оказаться на главной сцене

Вам не обязательно знать все о Kotlin или иметь многолетний опыт выступлений на конференциях, чтобы подать доклад. Вам нужна полезная история, понимание того, кому она может помочь, и четкое объяснение того, почему это важно.

Не каждое сильное предложение может быть отобрано. Программы конференций должны соблюдать баланс тем, форматов, уровней опыта и интересов аудитории. Если вашу заявку не приняли, продолжайте дорабатывать идею, делиться своими знаниями и искать другие возможности для выступления.

Возможно, ваш опыт — это именно то, что нужно услышать другому разработчику Kotlin.

Открыт прием заявок на доклад для KotlinConf 2027! Поделитесь своим опытом, идеями и экспертными знаниями о Kotlin с сообществом в Кракове.

Подать заявку

Узнать больше