This year the PyData London Conference will be doing double blind reviews, where reviewers will select the talks solely based on the quality of the proposals submitted. Please DO NOT include any identifying information in your proposal. That is, do not include links to previous talks, slides, repo, etc. Again, talk selection decisions will be made solely on the proposal itself and nothing else- so be sure to give some thought into writing your proposal! Here are some general guidelines and tips for you.
Please note that your proposal will not be reviewed by us until after the Call For Proposals (CFP) closing date, and that you can change your proposal as much as you want prior to the closing date. If there is anything unclear in your proposal, we will be reaching out with questions the two weeks after the CFP closes. Be sure to check your email late Feb/early March to respond to those questions!
A talk proposal is a short description of a talk that is aiming to convince someone to part with 30 minutes of their time, in order to learn about something. A good proposal should disclose:
- The topic (the WHAT) and WHY it is interesting
- The audience to WHOM the talk is addressed
- The TYPE of talk (lots of maths, hands-on, etc) and possibly the tone (light-hearted, informative etc)
- The TAKEAWAY, a.k.a. what will I learn
There are two parts to a proposal:
- Brief Summary - This informs attendees what the talk is about. Discloses the topic, domain and overall purpose. This is at most a few lines long, and will be printed in the conference programme.
- Description - This is a self-contained statement that summarises the aspects of the talk. It should be structured and present the objective of the talk, its outline, central thesis and key takeaways. After reading the description, the audience should have an idea of the overall presentation and know what to expect. The description should also make clear what background knowledge is expected from the attendees. Both this and the summary will be included in the talk details online.
While there is no strict template for this, you should make sure that the audience can understand why your talk is relevant for them.
These are 90 minutes hands-on sessions where you have the opportunity to lead a classroom so attendees can learn about a new skill/library/technology in a self-contained way, and have said materials available to students before-hand so they can follow suit. Guidelines for the tutorial proposal are the same as above, but the description should make clear what are the requirements for the class and how the materials are going to be distributed (e.g. github repo, links, etc).
Take a look at some of the proposals from last year’s schedule.
- Who’s the target audience?
Think about your target audience in terms of job role (data scientist, engineer, researcher, etc.) and experience. Being clear about who you are speaking to (and the background knowledge you can expect them to have) is helpful both to you as you prepare your proposal or talk, as well as to the audience considering whether your talk is a good fit for them to attend.
- Learning objectives
With your target audience in mind, clearly state what they are going to learn. This is what helps people understand if your talk is interesting for them.
We don’t require a rigid structure for your talk, but thinking critically about it will help you shape your proposal. In particular, make sure that there’s enough content to make the proposal interesting, but not too much so that your talk would feel rushed or cluttered. It’s not a bad idea to estimate how long each section of your talk will take.
- Clear title
A catchy title can be useful, but don’t overdo it. People should be able to have a rough understanding of what’s going on, just looking at the title. Your proposal and your talk should also be in line with your title.
- Get feedback
Ask friends and colleagues to review your description; bonus points if they are your target audience. Take time to tweak the final description if needed. Did you know that we also offer a mentorship programme for first-time speakers?
If you would like a mentor to help you improve your proposal, add a note to your proposal in the “Additional Notes” section. Tell us what mentors you would be most comfortable working with, eg: gender/ethnicity/academic background/time of day/mode of interaction etc, and we will try to match you with a mentor! Also note that you would have to submit your initial proposal significantly earlier than the CFP closing date to receive mentorship and then make improvements to your proposal.
Here are some common pitfalls that could lead to the proposal being rejected:
- Overly long proposal
Keep it simple and clear. Good proposals typically can provide all the important information within 200 words. This is not a strict limit, simply a suggestion to stay focused.
- Future work
While talking about future work is interesting and could be mentioned in your talk, the core content of the talk should already be shaped, and you should be able to describe it in your proposal. Don’t fully rely on future data collection or future prototyping, because things often don’t go as expected.
- Sales pitches
We are a community of developers and users of open-source scientific computing tools. You can reference your closed-source product or platform, but the audience will find the talk more interesting if they can try your techniques with the PyData stack. Your problem definition, proposed techniques and business domain are also interesting, but sales pitches are typically rejected.
- Repeated Talk
We have a strong preference for new talks, and new speakers, and as such, if your talk is already available online it is unlikely to be accepted for the conference.