The call for proposals for PyCon India 2018 has been up and running for a few days now. We already have quite a few exciting proposals, and it is only going to get better. The programme of a conference is undoubtedly the greatest part of the conference. It is in the talks and workshops that the participants can learn the most and speakers can make the most impact. Ever since the inception of tech conferences led by FOSS communities, talk selections have been a continuously-evolving process. PyCon India is now in its tenth year. In this time we too have gone through many different cycles of revising our talk/workshop proposals and selection processes. We pride ourselves on being not only adaptable but also welcoming towards change and learning from other conferences and communities.
This year, we have decided to engage with the audience (both speakers and attendees) well in advance of the talk proposal-review-update cycle in a very proactive manner. One of the many ways in which we hope to accomplish this is the mentorship programme for first-time speakers (you can read more about it here). Another step in that direction is laying down some guidelines about what makes a good proposal. That is what this post is about. We cannot emphasize enough that these are only guidelines, not rules, derived mostly from the experiences of Pythonistas who are regular speakers at tech conferences.
Before we get into the details, let us take a look at some myths that many novices have, about speaking at a tech conference.
An advanced talk is a good talk : As you can see in the CFP, the intended target audience for any talk or workshop is categorized under "Beginner", "Intermediate", and "Advanced". These categories have no correlation with the quality of a talk. Talks are evaluated not only based on their inherent depth but also on the impact they might have on the audience - and as such, good talks for beginners are much more likely to have an impact than mediocre talks for experts. We also tend to confuse beginner talks with easy talks. As Einstein famously said, "If you can't explain it simply, you don't understand it well enough." So, generating even the simplest content takes a lot of effort and expertise. Conversely, anyone can come up with a complicated and arcane material, but it means nothing without clarity.
Showing code is important : You may, under the right conditions, show snippets and templates of code, but live coding is generally a bad idea. A piece of code not working exactly when people are looking at it is something that happens so frequently that it is not even funny anymore. Moreover, code, by its very nature is not meant to reside on slides. Making an audience read the code, or even walking them through code wastes quite a bit of time. Yes, talk is cheap and you ought to show people the code, but a presentation is not the right place for it. Show snippets or templates and leave links for the audience to follow.
Upvotes are critical in selection : Upvotes on a proposal are only marginally important. They are used mostly as tie-breakers. The organizers are acutely aware that the people who upvote or downvote talks may not even attend the conference. Some authors go to great lengths to get their talks upvoted. This is a misdirected effort at best. This is not to say that there is no merit in promoting your own talk among your network and asking people to upvote your proposals. However, do remember that a popularity of a talk works only if it is organic. It is not uncommon to have mediocre proposals become very popular just because they have plenty of buzzwords in them. Such proposals stick out like a sore thumb and may easily be subject to stricter scrutiny.
Workshop slots are easier to grab than talks : It is no mean feat to keep an audience of 30 to 50 people sufficiently engaged for the better part of three hours. Workshops are, by definition, highly interactive and therefore, writing Jupyter notebooks for a workshop requires more effort than writing slides for a talk. It is true that the content for a workshop may not be as original as that for a talk, but since the audience is expected to code alongside the speaker and solve exercises in the course of the workshop, the content is subject to more criticism.
Loud proposals are more visible : A loud proposal here means too much of any of the following: memes, jokes (no matter how funny and non-stereotypical they may be), buzzwords or catchphrases, exclamation marks, religious jingoism towards or against a piece of technology, etc. Authors can rest assured that every single proposal will be given its due attention and care. The loudness, instead of making your proposal more visible, only makes it more difficult for the reviewers to sift through the noise and get to the real message.
These points themselves might have given you a broad idea of how the programme committees normally look at talk or workshop proposals, but there are quite a few details to follow. While there is no formula for a good talk, broadly each talk is judged on three aspects relevance, clarity and the potential impact of the talk.
The importance of the relevance of a talk to the Python community need not be emphasized. A talk about the internals of the Linux kernel, while irresistible to many of us, would not be a good candidate for a PyCon. One of the best ways of keeping things relevant is knowing your audience well. Spend some time looking at the well-received talks in other conferences, and try to balance your content accordingly. This is not to say that the history of a conference dictates its future content. On the contrary, many great talks come from breaking the glass ceiling. Keep in mind that it is very easy for audiences (and communities in general) to forget what is relevant to them, especially in this age of information overload where we are distracted by and attracted to every new article that goes viral on Hacker News. Consider this example - an interesting point of debate from a panel discussion last year was that Python has too many web frameworks. Now, your takeaway from this could be that no one wants to hear yet-another-talk-about-yet-another-web-framework. However, a very good proposal might emerge from evaluating different web frameworks, weighing their pros and cons, pointing out what could be done to fix problems, and a healthy dose of practical advice drawn from your own experiences, which would eventually motivate the audience to seek better solutions. A good speaker is one who steers the audience in a more relevant direction, even under the overload of information, just like a recommendation system. Be the best recommendation system you can be.
The clarity metric is simply a corollary to the first point made in the list of myths earlier. Keep in mind that ideas and concepts are far more sustainable in a talk than solutions and tools. And to be able to crystallize these in your presentation, clarity is paramount. The ideas themselves may be simple or complex, but they should be clear. What Donald Knuth said about writing code for computers and writing code for humans applies in conferences too. Conferences are nothing without people, and people, especially programmers, thrive on clarity of thought. When drafting your proposal, make sure that you clearly highlight the focal points. The remaining is just details, which should follow naturally.
The final aspect of the talk - its impact - can be both positive and negative. One way of determining the potential positive impact of your talk is by asking yourself questions like:
The negative impact of a talk is somewhat difficult to determine, but a few things that must invariably be avoided are toxicity, race/gender stereotypes and shaming, directed toward anyone - even toward a hypothetical individual - for any reason.
Do not forget to ask for help and take full advantage of the mentorship programme. Be active on the CFP. Actively engaging with reviewers and the audience in the comments section of your proposal can work wonders for your proposal. Note that conference slots are a very expensive affairs for everyone involved - the organizers, the speakers, and the audience. Part of the responsibility for making a talk successful lies with the organizers too. Therefore, we are as invested in your proposal as you are yourself.
All the best!