Imagine that you’re not the author. You’re a bored and tired reviewer who’s looking at submission number 122 out of 145. You can accept only 30 and already have 61 you want to say “yes” to and accepting any new submission would only make the choice harder. You read that next one ﹘ the proposal you submitted as the author ﹘ with the intention to reject it. “That’s unfair!” you’d say. “If it had been number 3, it would have been considered an acceptable one.” You wouldn’t have seen the other 15 submissions talking about the same issue yet, already accepted 61 out of 30, and so on, and so on. Where’s the objectivity, for crying out loud?
The truth is ‒ it doesn’t matter. Yours can be the very first, or the very last. You read the submission with objectivity, hoping it’s a no-go. But then you realize that it’s an excellent piece. It gives a unique overview, it’s timely and perfectly prepared, it’s going to be a must-attend. No, you cannot reject this one! You’re going to have to filter and cut out most of what you’ve already accepted, but on this particular submission you make a note for the program, “This one’s a must-have.”
The Highs and Lows of the Submission Process
The first time I submitted a talk for Open Source Summit EU back in 2018, I assumed that because I believed the topic to be awesome and interesting ﹘“Get Your Kubernetes Cluster on ARM” ﹘ so would everyone else. In the weeks following my submission, I simply waited for the email with the subject line containing that very important word “Accepted.”
Time passed and I received the long-awaited email: “I am writing to notify you that your submission for Open Source Summit has regrettably…”
Disappointed and confused, I wondered what prevented the reviewers from recognizing the potential of my submission. Didn’t they notice it was the best proposal ever sent to OSS?
Does this sound familiar? Considering the amount of rejected conference submissions in general, nearly 90% of the people reading this blog post should see themselves in this story.
Less than a year later, a presentation I submitted to KubeCon EU was accepted. It opened the door to conference after conference, as long as I submitted something, it got approved. While I was still struggling with writing a good proposal, I couldn’t explain why the first submission had been rejected and the following one accepted. The eye-opening moment, however, transpired when I had the opportunity to move from author to reviewer.
The Program Committee’s Selection Criteria
While you are spending time thinking about your proposal, living with it for a while, appreciating all the good learnings it could bring to the audience, the reviewer’s task, on the other hand, is very different. There are hundreds of submissions for a limited number of topic tracks for a given conference to review. The goal of the review process is to cull from the herd, selecting only the best of the best. This protects the reputation of any particular event, ensuring that attendees receive the high-quality content they expect.
When deciding on the highest quality content, there are four aspects considered most important:
- Content relevance
- Overall content quality
- Delivery expectations
Let’s take a deep dive into each aspect to get you effectively prepared in crafting your next submission.
Amongst the tens and hundreds of topics within a given discipline, a large number of proposed presentations cover similar problems and solutions. To make your submission stand out, you need to strongly state what makes it unique (and valuable). In fact, citing a unique personal experience goes a long way.
Some topics are a must-share and important in raising awareness. They are usually rare amongst proposals, which indicates that they should be more widely discussed. You know about an open source pain point? Identify the value to the community and share it.
To make your submission stand out, you need to strongly state what makes it unique (and valuable)﹘in fact, citing a unique personal experience goes a long way.
Conventionally, most of the event attendees are looking for emerging innovation and focus on cutting-edge development practices. Are you a container expert? Could your talk address nextgen container orchestration, a world post-Kubernetes? You may have a winner there.
2. Content relevance
Your content should be relevant to the conference and relevant to the topic. If it’s a cloud-native conference, talk about cloud-native technologies. If it’s an open source event, talk about open source. If you state in the topic that it’s going to be about open source, don’t build 99% of the content around your great enterprise project. This can be misleading and disappointing for those who come with the wrong expectations.
NOTE: The submission abstract must contain justification of the significance and importance of your topic.
Your audience should leave the room with important and impactful takeaways and consider time learning from you well spent. Think about what value your message brings to them and how you plan to structure the delivery. Provide new and exciting content rather than information that was last year’s news. Following our Kubernetes example, a key takeaway may be “enabling hybrid cloud application deployments is a key part of Kubernetes’ future.”
Stay focused and on track. People should know what you’re going to talk about, why you’re going to present it and leave your presentation with their expectations met.
At the end of your presentation, your content should meet the audience’s expectations.
3. Overall Content Quality
Ultimately, there is one thing that you want to convince the reviewers: that your submission is better than all other related submissions. It’s not an easy task given that you don’t know anything about the other applications. However, there are more helpful hints we can provide that may have the potential to transform your submission into a “mission possible:”
- Provide a complete application. One would hardly believe that your talk, panel discussion, lightning talk, BoF, etc., is going to be well-organized if your application is not.
- Make a clear problem statement. It should thoroughly describe the background of your effort, give a clear and concise statement about the topic, and have a well-defined hypothesis. It should not lack focus and sound too vague and broad.
- Craft your proposal to be technically sound. Make sure it provides enough details, describes the objectives and the strategy thoroughly, explains the results and supports the conclusions. You want to leave the reviewers with the impression that it’s thought out and doesn’t need any improvement.
- Be original with your takeaways! A winning submission is one that introduces new and original ideas, supported by research content and/or concept or one that describes an emerging topic or is in an area that is not yet well understood.
4. Delivery Expectations
The application content is important, but it doesn’t seal the deal making it a good part of the program. Delivery does. This is the hardest task for a reviewer to decide on, without having seen the presenter give a talk. However, if it’s not a fully blind review, take advantage by providing a link to a talk you’ve done that aligns with your proposed content and promotes your good technical and presenting expertise. Bear in mind this is not the time to be modest! Tell them who you are and why you are the best person in the industry to tell this story.
If you don’t have any presenting experience, don’t let that stop you. Newcomers are always welcomed.
A good delivery also means that your proposal is going to be engaging from start to finish. Make sure it is clear to a reviewer what is going to be presented for the whole time period and how it’s going to be presented, with any extraneous details removed. Drawing on our Kubernetes example: “I am going to discuss innovative technology in a container and cloud-native area, then elaborate on container runtime, image building and delivering improvement, show how we approach container networking, talk about container practice in large organizations, and public cloud services; and which industries are actively engaged implementing the technology; and how organizations can get started in this direction.”
And last but not least, understand that part of your responsibility as a speaker is to encourage your audience to care, help and engage in the community and ecosystem.
Do’s and Don’ts
Another good tip? Have a colleague, preferably a fellow subject matter expert, proof your application before you send it in.
One Final Consideration
With all the practical guidance we’ve already given, we can add only one more bit of advice: Write that submission for the most censorious reviewer who has ever existed!
Good luck and we hope to see you at the next event!
Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.