Call for Proposals

PyData brings together analysts, scientists, developers, engineers, architects and others from the data science community to discuss new techniques and tools for management, analytics and visualization of data. PyData welcomes presentations focusing on Python as well as other languages used in data science (e.g. R, Julia). Presentation content can be at a novice, intermediate or advanced level.

We’re accepting proposals until March 29th

Submit a proposal here

Proposal Guidelines


A talk proposal is a short description of a talk that is aiming to convince someone to part with 30 minutes of their time, 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)
  • The TAKEAWAY, a.k.a. what will I learn

There are two parts to a proposal:

Brief Summary - This informs the attendee 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 program.

Description - This is a self-contained statement that summarizes 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 abstract, the audience should have an idea of the overall presentation and know what to expect. The abstract should also make clear what background knowledge is expected from the attendees.

While there is no strict template for this, you should make sure that the audience can understand why your talk is relevant for them.


Are you a first-time speaker, or just want some extra help preparing your proposal? PyData Amsterdam offers mentorship to help you make the most of your proposal and/or talk. Reach out to us on [email protected] if you are interested.


These are 180 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 abstract 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).

Tutorials shorter than 180 minutes are also acceptable, but keep in mind that doing hands-on work in less time is much more difficult to organise. We would like to see your approach described in the proposal. Please make it clear in your proposal if you plan to spend less than 180 minutes.


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.

Outline - 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 abstract; bonus points if they are your target audience. Take time to tweak the final abstract if needed. Did you know that we also offer a mentorship program for first-time speakers?

Common Pitfalls

Here are some common pitfalls that could lead to the proposal not being understood by the reviewers, or even rejected:

Overly long proposals: 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 talks: We have a strong preference for new talks and new speakers, and as such, if your talk is already available online or it has been already presented in PyData, it is unlikely to be accepted for the conference.

Examples from last year

Some good proposals from last year include: