Proposal Tips, Part Two

Understanding the Form (and other things also)

Our first article on proposal submission gave some general advice on how to put together a compelling abstract and generally approach the process. This article will focus on each major section of the submission form, and then cover a few extra aspects that didn’t quite make it into the first article.


Your Speaker Profile: Additional Tips


In order to submit a talk proposal, you will first be required to complete a profile. Much of this is straightforward and instructions are provided throughout the online form. However, here are some additional tips for the “Biography” and “Speaking Experience” sections of the profile form.


Biography:

As this will appear publicly on the conference website and the program, the biography section gives you a chance to let conference attendees know a little about who you are and your python background. Your background could be deeply technical, you may be a student, an avid enthusiast, a teacher or any other accurate description.


This kind of information can help conference attendees understand the perspective you may bring to the topic of your talk. The program committee will also take this into consideration when considering your talk submission. (Note: should you wish to provide the program committee with additional information about your background, that you do not wish to be shared publicly, please do so in the “Private Abstract and Timing Overview” section of the talk proposal submission form).


Speaking Experience:

As the online form instructions explain, please provide a brief description of your speaking experience. PyCon AU strives to include speakers with a range of experiences - our community benefits from presentations delivered by extremely experienced speakers, first-timers and everyone in between.


For first-time speakers: if you have never spoken at a conference or similar event before, that is totally fine - we encourage applications from would be first-time speakers. In this case, it is fine to simply say “I have not spoken at a conference before, if accepted this will be my first conference talk” or something along these lines. If you have other relevant experience - eg. debating experience, committee chair - feel free to list it here. If you don’t have other relevant experience, that is fine too.


Your Talk Proposal: Additional Tips


Once you have completed your profile, you will need to submit a proposal for your talk. Once again, instructions are provided throughout the online submission form. Here are some additional tips for some sections of the proposal form.


Proposal Title:

Clarity is important here. While everyone loves a catchy or funny title, it is actually far more important for conference attendees to be able to quickly identify what your presentation will be about. (Of course, if you can make your title both catchy and clear, that is great, but it is not required). Also, please remember that your title must comply with the PyCon AU Code of Conduct, so cannot include inappropriate language or references. Disrespectful references to coding languages, platforms, browsers and such like are also inappropriate.


Target Audience:

A common question from would be speakers is - who attends PyCon AU and who would my target audience be? The long answer is:


PyCon AU attendees come from a broad range of backgrounds and levels of experience. Attendees have backgrounds in web stuff, hardware, software, education, science, AI and pretty much every area you can think of. Some attendees have been coding since the time of punch cards and before the internet existed, some have just started to learn how to program and everywhere in between. Chances are if you have something interesting to say, there will be conference attendees who will want to hear about it.


The online proposal form gives you four options to select for the target audience -

  • Introductory (should be of interest to someone new to the topic)

  • Intermediate (should be of interest to people familiar with the topic, as well as people with a general background in Python)

  • Specialised (mainly of interest to people with a strong interest in the topic)

  • General Community (a general topic of interest to a broad cross-section of people who use python)


The program committee endeavours to include talks that cover the full range of target audiences and a wide range of topic areas. So go ahead and select the target audience that you think would be best suited to your talk. In the event that the program committee thinks your talk proposal is fantastic, but would like to see the content tweaked to a different target audience to the one you selected, we will get in touch.


Abstract:

If your talk is accepted, this abstract will appear in the conference program. It is advised that your abstract be up to about 500 words. The first article covers a number of things to keep in mind while writing your proposal, but here is some more specific information.


The abstract gives you a chance to inform conference attendees about what your talk will cover.


Your abstract must comply with the Code of Conduct - so please ensure your language and content are appropriate and inclusive for diverse audiences from ages 12 and upwards. If you have any questions as to suitability of any aspect of your talk, please email us at program@pycon-au.org. Similarly, language/platform/browser/OS bashing is not welcome either.


The abstract is your chance to both explain what your talk will comprise, and also to engage the interest of the audience. This was discussed to some degree in our first tips post and also in the linked articles in that post. If after reading those, you would still like some more ideas and inspiration, consider taking a look at last year's program. The abstracts are all still online, and you could take some notes from your favourite sessions.


The use of humour can be very engaging and grab people’s attention - as can other kinds of tone or emotion. However, conveying tone and humour well in written form can be trickier than it might appear! If you can write a good proposal which is going to engage the audience emotionally as well as through interest in the technical content, you will definitely get people’s attention and get your message through more effectively. However, it’s even more important to be easily understood.


Private Abstract and Timing Overview:

This abstract will only be shown to the conference organisers and proposal selection committee. If you have any details about your proposal and/or your background, that you do not wish to be made public, include them here.


It is also important to provide a breakdown of the timing of your talk, so that the program committee can see what your talk would cover and that you have considered how to structure your talk. You can structure the time however you wish, however, your timing breakdown needs to be specific.


In case it is instructive, here are two examples of timing breakdowns that lacked detail and did not tell a compelling story. These are both real examples from submissions to PyCon AU 2016, which have been reprinted here with the authors' permission, neither of which were accepted into the 2016 program.


Less Strong Example One:

    0-5 minutes: Personal introduction

    5-10 minutes: Python in the workplace

    10-15 minutes: Key Python technologies for teaching

    15-20 minutes: Key workplace skills

    20-25 minutes: Opportunities for new developers

    25-30 minutes: Q&A


Less Strong Example Two:

    0-5 minutes: personal introduction

    5-10 minutes: problem statement, what are we missing out on as a community?

    10-15 minutes: Gaps in the current approach (use of JS libraries and frameworks)

    15-22 minutes: Why can't we just X where X in [new browser, PyPy.js, Kivy]

    22-25 minutes: Closing and next steps

    25-30 minutes: Q&A


By contrast, here is a very strong example (this was also part of a real submission to PyCon AU 2016, this talk was accepted into the 2016 program, reprinted here with the author's permission):


0-2 minutes:

  • Introduction to the talk, “why we’re talking about mental health”

  • Examples of developers who’ve spoken about their experiences


2-7 minutes: Kinds of mental health (it’s not just depression!)  eg.

  • Stress

  • Anxiety

  • Depression


7-14 minutes: How and why are developers at risk?

  • Risk factors in mental health

  • Common development processes


14-20 minutes: Strategies; What we can do to make our environments better

  • Individual Level

  • Teams (coworkers, family, friends)

  • Company wide (workplaces, management)

  • Communities


20-25 minutes: How can technology help

  • Direct tools (eg. mood trackers)

  • Indirect tools (organisational, entertainment, relaxation)

  • THE FUTURE


25-30 minutes: Questions


In the last example, the program committee could see the specifics of what was going to be included; that the author has worked out how to structure the content, and that the content would fit within the length of the talk.  Providing this detail also allows the selection committee to get in touch with you if they have any questions or suggestions regarding your talk content.


Some other submissions that were put forward in 2016 had a similar amount of detail, but clearly included more information than could possibly be covered in the duration of the talk.


Random Tips that Didn’t Fit Anywhere Else


On Live Coding


This frequently goes wrong. If you are considering doing this, be prepared for what might happen if an issue comes up, and whether you will be able to adapt to the situation at hand. If so, then by all means go ahead. Here are some suggestions:


  • Consider https://github.com/rfk/playitagainsam if all you want to do is demonstrate typing

  • Have screenshots or slides as backup should the interactive element fail

  • Consider how long any parts of your demonstration might take - any time-consuming aspects of the live demonstration may result in losing the attention of the audience

  • Consider how to fill in time or recover from any mistakes or problems

  • Make sure the live demonstration has a specific role to play - giving a live demo isn’t necessarily compelling in and of itself


Rehearsals and Preparation


There are a variety of views on how to prepare. Some people put a lot of time into both their proposal submissions and also into rehearsing their talk prior to the big day. Others are very familiar with the last-minute slide editing rush, often finalising their content at the venue in the hallway. Different people find their inspiration, motivation and confidence in different ways. Here are some suggestions for different techniques you could use to prepare:


  • Record a video of your presentation and watch it back

  • Run through the slides by yourself, talking through the slides to check the timing

  • Present at a local user group and gather audience feedback


Have Fun - It's an order! ;) 


If you’re still reading this document, you could be forgiven for getting a bit tizzy about all the things you need to keep in mind. The point of providing all this information isn’t meant to overload presenters with an excess of concern, but rather to answer questions for people who are wondering about how to deal with some aspect of preparing their presentation.


The Python community is generally one of the nicest, kindest, most supportive technical groups you will find. If you make a mistake, don’t worry about it. If your presentation isn’t perfect, that’s okay too. If you’re worried about whether it’s good enough - try not to worry so much.


Speaking at conferences is incredibly rewarding in many ways. It’s a great way to start to form a community network, to meet people and start new conversations with people. It’s great experience for improving public speaking ability, and doesn’t look too bad on a resume either. It can also be a lot of fun. It’s a chance to pull together the threads of an idea, to create something and to get out in front of your peers and see how it goes.


So enjoy the process, regardless of what the outcome is, and have fun.



Sponsors