What Makes a Great KotlinConf Proposal?

TL;DR · AI 摘要
撰写成功的KotlinConf提案需聚焦实用经验、明确受众,并突出独特价值。
核心要点
- 初学者提案可从日常开发问题的解决方案切入,无需宏大主题
- 提案需明确核心故事,避免泛泛而谈技术概念
- 摘要应包含具体案例和可执行的实践建议
结构提纲
按章节快速跳转。
- §引言
介绍KotlinConf 2027征稿启事及提案价值判断标准
强调实用经验比技术深度更重要,提供受众验证方法
要求提案需围绕具体开发场景的故事展开
包含标题、摘要、核心洞见的三段式结构规范
- ›常见误区
指出过度追求技术术语会削弱提案说服力
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- KotlinConf提案撰写指南
- 核心原则
- 实用优先
- 故事驱动
- 结构要素
- 明确受众
- 案例支撑
- 常见问题
- 技术术语陷阱
- 经验不足焦虑
金句 / Highlights
值得收藏与分享的关键句。
初学者提案可从日常开发问题的解决方案切入,无需宏大主题
若能找到至少两人对主题感兴趣且愿意倾听超过五分钟,即具备提案潜力
摘要应包含具体案例和可执行的实践建议,而非泛泛而谈技术概念
什么样的提案才能成为优秀的 KotlinConf 演讲? - JetBrains 博客
Kotlin
由 JetBrains 开发的简洁多平台语言
关注
- 关注:
- X X
- RSS RSS
访问 Kotlin 官网
Kotlin
KotlinConf
什么样的提案才能成为优秀的 KotlinConf 演讲?
KotlinConf 2027 征稿现已开启!我们邀请来自 Kotlin 社区的开发者们,将你们的创意、经验与专业见解带到克拉科夫的舞台。
你是否有一些 Kotlin 相关的课程内容或发现,能够帮助其他开发者?也许你解决了某个复杂的技术难题,将 Kotlin 引入了现有代码库,构建了令人意外的项目,或者从一个未达预期的方案中获得了宝贵的经验。
这些经历都可以成为 KotlinConf 的演讲内容。
提交你的提案
然而,将一个想法转化为有说服力的会议提案可能颇具挑战,尤其是如果你从未提交过提案。你如何判断自己的经验是否值得分享?评审人员首先会关注什么?摘要需要多详细?如何让一个常见主题脱颖而出?
为了帮助你准备提案,我们向 Kotlin 开发者、开发者倡导者、经验丰富的演讲者以及 KotlinConf 计划委员会成员请教了什么构成强有力的提案。除了关于如何塑造标题、摘要和收获的实用建议外,我们还新增了一个特别重要的部分:当评审人员打开提案时,他们首先注意到的是什么?
首次演讲?请依然提交你的想法!
很容易认为 KotlinConf 的演讲必须始于突破性发现、大型生产系统或多年的演讲经验。实际上,有价值的演讲可以始于一个简单的想法,或在解决日常开发问题时学到的教训。
你不需要精通 Kotlin 的方方面面——你只需要有值得分享的内容,并清楚它能帮助谁。
#### Pamela Hill-Galloway. 开发者倡导者,KotlinConf 计划委员会成员,KotlinConf 演讲者
X , BlueSky , LinkedIn
请依然提交你的想法!KotlinConf 上有一些非常成功的演讲,最初只是基于一个简单的想法。
如果你不确定自己的主题是否会引起他人兴趣,请与身边的人讨论。向同事、朋友、用户组成员或 Kotlin 社区的人解释这个想法。他们的提问和反应可以帮助你理解哪些部分最有价值。
#### Marcin Mycek. 产品经理,Kotlin 构建工具
如果你能找到一个感兴趣的人,很可能还有更多!如果你能找到至少两个身边对主题感兴趣且能专注聆听超过五分钟的人,这已经是一个不错的候选提案。
无需先前的会议经验。基于你真正理解和关心的事物,一个清晰且真实的提案可能比一个内容空洞但打磨完美的提案更具说服力。
- 其他开发者可以借鉴你学到了什么?
你的故事不一定要来自大公司或服务数百万用户的系统。如果一个小项目能提供原创见解或清晰解释复杂主题,其专注的教训同样有价值。
尝试用一句话总结核心观点,例如:
本次演讲将向[听众]展示我们如何[解决问题或探索某事],我们学到了什么,以及他们如何应用这些经验。
如果你无法清晰完成这个句子,可能需要在撰写提案前进一步完善这个想法。
评审者首先注意到什么?
标题可能是评审者阅读的第一行内容,但整体的用心程度会很快显现。
评审者不仅关注主题是否有趣,还会评估演讲者是否能清晰解释内容。一个经过深思的标题、聚焦的描述、具体的收获以及精心的排版,都表明你投入了时间打磨想法。
我可以总结为:你在撰写提案时的用心程度,可能比你想象的更显而易见。如果我能看出你花时间构思了一个既吸引人又贴合内容的标题,我会更倾向于在KotlinConf上批准你演讲。如果你的描述过于简短或冗长,或者明显是AI生成的,导致无法清晰简洁地表达想法,我可能不会为你投票通过。
这并不意味着你需要使用复杂语言或打造完美的营销文案。关键在于给评审者足够的信息让他们理解你的想法,并展示提案体现了你个人的经验和声音。
Marcin Moskała的《Taming Asynchronous Beasts: Debugging and Performance Tuning in a Coroutine World》提供了一个精准承诺的典范:“你将学习如何有效使用内置工具、识别有问题的模式,并实施经过验证的优化策略。”
撰写清晰且信息丰富的标题
一个有力的标题应让评审者和最终听众准确了解演讲内容。
创意可以让标题令人难忘,但清晰度应始终优先。避免完全依赖笑话、引用或隐喻的标题,而没有解释主题。
精心选择的标题能产生巨大差异!听众在决定是否参加演讲时,往往没有足够的时间或注意力去阅读超过标题的内容。优先选择清晰度,而非仅为了吸引眼球或趣味性却无法概括演讲核心的标题。
比较以下标题示例:
过于宽泛:Our Multiplatform Journey 更具信息量:What We Learned Migrating Our Mobile App to Kotlin Multiplatform
过于模糊:Coroutines Gone Wild 更具信息量:Debugging Coroutine Performance Problems in Production
过于笼统:Building Better APIs 更具信息量:Designing Type-Safe Kotlin APIs That Are Difficult to Misuse
一个好的标题通常至少传达以下两点中的两点:
- 核心主题
- 遇到的问题或提出的问题
- 探索该主题的背景
- 对听众的实际价值
- 预期的技能水平
你仍然可以使用幽默或文字游戏,但确保标题不会掩盖会议的实际内容。
摘要不需要包含您整个演示的内容。然而,它应提供足够的细节,使评审人员能够理解问题、演讲方向及其价值。
两到三段聚焦的段落通常比单句模糊描述或涵盖所有细节的长篇描述更能有效传达信息。
#### Sebastian Sellmair。软件开发人员和 KotlinConf 演讲者
X , BlueSky , YouTube
在 KotlinConf 上演讲是一次绝佳的体验,也是任何 Kotlin 开发者的重要成就。虽然选择一个优秀的标题、制作高度精炼的动画、整理高质量的表情包可能会提升您的演讲效果,但最重要的是拥有值得讲述的故事。您是否有新颖且技术上有趣的内容可以分享?您能否以引人入胜且真正有趣的方式拆解某个主题?您能否激励其他开发者?
#### Márton Braun。开发者倡导者、KotlinConf 计划委员会成员和 KotlinConf 演讲者
虽然我们不需要演讲的完整脚本作为摘要,但仅用一句话作为摘要的演讲我们通常不会接受。两到三段通常足以提供有意义的细节。
一个简单的结构可以帮助您:
背景
介绍情境和可能对此情境有所认知的受众。
挑战
解释推动工作的具体问题、限制或疑问。
#### Jodie Burchell。开发者倡导者和数据科学家
LinkedIn , Mastodon , BlueSky
通过告诉听众您将解决的问题来吸引他们。人们喜欢悬疑小说是有原因的,因为它们在揭晓解决方案前会营造一些悬念。优秀的提案也会产生类似的效果。
方法
描述您探索、实现、比较或发现的内容。
结果
阐明听众将学到什么以及如何应用这些内容。
一个有力的收获可以像 Tadeas Kriz 在《Dependencies and Kotlin/Native》中提到的那样具体:“学习原生依赖项如何交互、如何加载,以及原生世界中令人意外的复杂性。”
#### Chantal Loncle。软件开发人员、Exposed、JetBrains
避免模糊的承诺。改用行动动词和具体成果来描述听众将获得的确切能力和转变。他们离开演讲时是否会感觉时间被充分利用?如果是,他们将带走哪些实用知识、可立即应用的技能或高价值工具?
例如:
维护独立的 Android 和 iOS 实现使我们的团队能够独立推进,但也导致了业务逻辑重复和应用间行为不一致。
在本次会议中,我们将探讨如何逐步引入 Kotlin Multiplatform,从共享一个功能开始,而不是尝试全面迁移。我们将讨论如何选择第一个组件、构建共享代码、跨平台测试以及与现有原生应用协作。
您将获得一个实用框架,用于评估在何处引入共享代码、预期哪些挑战,以及如何规划渐进式的 Kotlin Multiplatform 采用方案,而无需重建整个应用。
这个示例明确了问题,解释了会议内容,并为听众提供了参与的理由。它没有透露所有细节,但做出了具体的承诺。
以参会者视角思考
一个强有力的提案不仅关注演讲者想要呈现的内容,还会说明听众将获得什么。
- 这个会议适合谁?
- 与会者需要具备哪些先决知识?
- 这场演讲将帮助他们解决什么问题?
- 演讲结束后,他们将理解什么或能够做到什么?
- 为什么应该选择这场会议,而不是同时进行的其他演讲?
#### Svetlana Isakova。Kotlin 开发者倡导团队负责人,KotlinConf 计划委员会成员,KotlinConf 演讲者
X
提交演讲时,请以参会者的身份思考。你愿意花时间听这场演讲吗?听众能从中获得什么?这就是我们询问关键收获的原因。你希望人们学习、尝试、实践或受到启发的是什么?
避免使用宽泛的承诺,例如:
- “你将学习最佳实践。”
- “我们将探索 Kotlin Multiplatform。”
- “这场演讲将涵盖协程。”
改用具体的成果描述:
- 与会者将学习如何识别和调试三种常见的协程性能问题。
- 与会者将理解我们如何在 Android 和 iOS 之间构建共享代码。
- 与会者将能够评估这种方法是否适用于自己的项目。
- 与会者将了解我们迁移过程中哪些部分有效、哪些无效,以及我们今天会如何改进。
具体的关键收获使提案更容易评估。如果演讲被选中,这些内容也能帮助与会者判断其是否与自身相关。
让熟悉的话题焕发新意
你的主题不一定要完全新颖。许多有价值的会议演讲会从此前未被深入探讨的角度重新审视已有的技术。
如果你要提交一个热门话题,请明确你的版本有何独特之处。这可能包括:
- 一个真实的生产案例
- 非同寻常的规模或环境
- 意外的结果
- 一次失败的尝试及从中获得的经验
- 几种可能解决方案之间的对比
- 逐步迁移而非全新实现
- Kotlin 的非常规用法
- 挑战常见假设的个人经历
- 一种特别清晰的解释复杂概念的方式
例如,“Kotlin Multiplatform 入门”是一个宽泛且常见的主题。而“当我们将 Kotlin Multiplatform 引入一个七年历史的移动应用时发生了什么”则提供了具体的背景并引发好奇。
诚实地说明权衡取舍。一场演讲不需要呈现一个完美无缺的成功故事。解释哪些地方失败了、哪些发生了变化、以及你如果重来一次会如何改进,对其他开发者可能特别有帮助。
将一个真实、实用的叙事带入熟悉的话题中,可以增强提案的说服力。诚实地说明哪些地方出了问题、哪些让团队感到不满,或者如果能倒转时间你会如何改变。当从一个明天将首次遇到相同问题的人的视角来看,一个熟悉的问题也可能显得耳目一新。
与其再提供一个泛泛的概述,不如围绕一个具体的痛点或发现来构建演讲,仅在支持该故事时引入更广泛的主题。一个与会者可以立即应用到自己工作中的收获,也能帮助提案区别于基础教程。
保持提案与 KotlinConf 的相关性
KotlinConf 欢迎关于后端开发、Android、多平台开发、Web、桌面应用、人工智能、语言设计、工具链、库、开发者体验以及 Kotlin 生态系统其他方面的演讲。
无论您所在的领域是什么,Kotlin在故事中扮演的角色都应清晰明确。
请记住,您的演讲内容必须与Kotlin相关!例如,并非所有关于Android的演讲都一定适合KotlinConf的观众。或者,关于Jetpack Compose的演讲经常涉及与Compose Multiplatform完全相同的工作方式,而后者更有可能被KotlinConf接受!
例如,一个Android主题并不自动成为KotlinConf的主题。当提案解释Kotlin如何影响解决方案、探讨特定于Kotlin的技术决策,或提供Kotlin开发者可以应用的经验时,提案的相关性会更高。
- 为什么这是一个与Kotlin相关的故事?
- 这次体验中哪些部分对Kotlin开发者特别相关?
- 如果移除Kotlin,提案的核心内容是否仍然保持不变?
如果对最后一个问题的回答是肯定的,请在提交前加强与Kotlin的关联。
Anshika Koul在挪威邮政的演讲《Kotlin Multiplatform在挪威377年国家邮政服务中的跨平台优势》就是一个以Kotlin为中心的典型案例:"我们将学习KMP如何通过统一的框架,在不同平台上实现代码共享和执行,从而解决不同代码库针对不同运行时的挑战。"
保持自信,但忠于自我
您的提案应展示您清楚了解想要分享的内容及其重要性。
这并不意味着夸大自己的专业知识或假装没有疑虑。这意味着将想法表述为明确的陈述,而不是反复质疑其价值。
保持陈述为陈述,疑问为疑问。自我怀疑是正常的,每个人都会这样,但常见的错误是让这种怀疑在文字中表现出来,例如将陈述句改为疑问句。阅读您的提交内容,或者更进一步,请他人阅读并问自己:这个人是否对自己的讲述内容充满信心?
不确定的表述:Kotlin Multiplatform是否可能帮助团队减少重复的业务逻辑?在这次演讲中,我们或许可以找到答案。
更自信的表述:在这次演讲中,我将展示我们的团队如何利用Kotlin Multiplatform减少重复的业务逻辑,包括代码共享带来帮助的场景以及未带来帮助的场景。
自信不应抹去您的个性。提案仍然应体现您的个人风格。
忠于自我!确保您的提交内容能被他人理解非常重要。一个很好的实践是将其交给几位您信任的人,询问他们从中理解了什么以及这种内容让他们产生了怎样的感受。但请保持真实的自我。许多优秀的演讲之所以令人难忘,正是因为他们独具特色、不拘泥于最佳实践,而人们正是为此而来。
建议和模板可以帮助您整理思路,但不应让每份提案听起来都千篇一律。您的视角、语言、幽默感和热情正是使提交内容令人难忘的部分。
向评审展示您的沟通方式
过往演讲的示例可以帮助评审了解您的表达风格和感染力。如果您有会议、聚会、网络研讨会或直播的录像,请包含最相关的内容。
如果您是首次演讲者且没有正式录像,可以录制自己讲解提案部分内容的视频。简单的笔记本电脑录像即可,不需要专业的灯光、剪辑或制作。
您的过往演讲示例有助于我们做出更优的选择。如果您是首次演讲者且没有录制视频,不用担心!您只需在笔记本电脑上录制自己(甚至只需录制提案中演讲的一部分)并分享链接即可。我们非常感激您的支持。
根据主题的不同,您还可以附加以下内容:
- 一篇技术文章
- 一个开源项目
- 您撰写过的文档
- 一段简短的技术演示
- 一次播客或线下活动的参与经历
- 与提案内容相关的其他作品
这些材料可以支持您的提案,但不能替代清晰的标题、摘要和收获点。评审人员仍应能仅通过提案本身理解演讲内容。
选择与主题契合的格式
并非所有主题都需要完整的演讲时长。
一个聚焦的课程、实验、副项目或令人惊喜的发现可能更适合闪电演讲。涉及大量技术背景、多个关联课程或详细演示的主题可能需要常规演讲形式。
根据您拥有的实质性内容数量选择格式。如果您需要重复内容或添加无关信息来填满常规演讲时长,请考虑提交闪电演讲提案。
请记住我们同样接受闪电演讲!如果您觉得内容需要填充才能达到常规演讲时长,作为闪电演讲可能反而更有趣。
如果您有多个不同的创意,也可以提交多个提案。每个提案应拥有独立的故事、受众群体和收获点,而不是另一个提案的次要变体。
提交多个演讲提案吧!这将为您带来更多参与KotlinConf的机会。
提交前请审查提案
完成初稿后,请暂时搁置并稍后以初次接触该创意的人的视角重新审视提案。
检查您的提案是否能回答以下问题:
- 仅凭标题,能否让人理解演讲的主题?
- 与Kotlin的关联是否清晰?
- 摘要是否明确指出了一个真实的问题、疑问或故事?
- 是否明确说明了该演讲的目标受众?
- 收获点是否具体明确?
- 提案是否解释了您的视角有何独特之处?
- 所选格式的范围是否合理?
- 表达是否自信且真实?
- 是否检查了拼写、语法、链接和格式?
- 提案是否听起来像是将要进行演讲的人所撰写的?
也请其他人帮您审查提案。与其简单询问他们是否喜欢,不如请他们描述他们认为演讲将涵盖哪些内容以及期待学到什么。他们的回答将显示提案是否准确传达了您的意图。
再次确认目标受众水平是否与描述和预期收获相匹配。请以您希望出现在观众中的那个人的视角审查提案。当前内容是否清晰易懂,还是缺少了对您而言显而易见但对评审或未来观众而言重要的背景信息?
AI工具可能帮助您检查语法或整理思路,但最终提案应反映您自身的经验、想法和声音。没有具体或真实见解的精炼摘要,不如清楚体现演讲者个性的摘要具有说服力。
你的提交内容应体现出你投入了思考和精力进行准备。请检查提交内容的格式问题和拼写错误,不要提交由大型语言模型生成的摘要。
你的 Kotlin 故事可能登上舞台
你不需要精通 Kotlin 或拥有多年会议经验才能提交提案。你需要的是一个有价值的故事、对目标受众的清晰认知,以及明确说明其重要性的解释。
并非所有优秀的提案都能被选中。会议日程需要平衡主题、形式、经验水平和观众兴趣。如果提交未被接受,请继续完善想法、分享知识,并寻找其他展示机会。
你的经验可能正是另一位 Kotlin 开发者亟需听到的内容。
KotlinConf 2027 征稿现已开启!在克拉科夫与社区分享你的经验、见解和 Kotlin 专业知识。
KotlinConf 2027
- 分享
上一篇博客
KotlinConf 总结:来自 Verifone 架构师关于 Kotlin 在关键支付系统中应用的经验教训 /