# Bonus Resources * Lara Hogan [Demystifying public speaking](https://larahogan.me/speaking/) * Damien Conway [Instantly Better Presentations](https://www.youtube.com/watch?v=W_i_DrWic88) * VM Brasseur [Public Speaking Resources](https://github.com/vmbrasseur/Public_Speaking#writing-presentations) * William Brown [The History of - History and Politics - William Brown](https://www.youtube.com/watch?v=q2VmIUaOS9o&t=3623s) ([context](https://www.youtube.com/watch?v=AJqcxEzRdSY&t=1119s)) * Zach Holman [speaking.io](https://speaking.io) * PyCon AU 2021 [Speaking Guide](https://2021.pycon.org.au/speak/) # Original Slides


_This post is based on the CFP Abstract Writing Workshop, presented at MelbDjango, May 3rd 2023._ So you want to write a talk for PyCon AU or DjangoCon AU? Let's talk about that! ## PyCon AU and DjangoCon AU PyCon AU is a five-day conference run annually (with a short break in 2022). Typically: * Friday is dedicated to "Specialist Tracks", * Saturday and Sunday to the General Conference, and * Monday and Tuesday for Development Sprints and other activities.
As PyCon AU grew, it expanded to having four tracks running. On the weekend, this is four rooms running at the same time, where attendees would have to choose between what to go and see. For Friday, each room would have a dedicated theme. DjangoCon AU has had a room at the Friday of PyCon AU for a number of years, and is returning for the ninth year in 2023. Other specialist tracks this year include the Education Track, All Things Data!, and Our Connected Universe. [More about specialist tracks on the pycon.org.au website](https://2023.pycon.org.au/program/#specialist-tracks). DjangoCon US, run by [DEFNA](https://www.defna.org/), and DjangoCon Europe, run in different cities each year, are run as separate conferences. DjangoCon AU chooses to co-locate with PyCon AU. As a co-located event, both DjangoCon AU and PyCon AU use the same system for accepting proposals for talks. Talks at PyCon AU are by Call for Proposals (CFP) submission, which go through a thorough review process. Usually, only keynotes are invited to speak, all other content goes through review. [More about the review process.](https://2023.pycon.org.au/program/#cfp-review-and-selection-process) ## Talk format Typically, talks are 30 minutes long. But, if you want to talk more about your topic, you can ask for a 70 minute "deep dives". These slots are limited. There is also the PyCon AU Fair, where you can get a poster and a table at an exhibition hall. [More about talk formats](https://2023.pycon.org.au/program/#talk-slots-and-timing) and the [Fair](https://2023.pycon.org.au/program/#new-pycon-fair'). ## Conference Proposal Nomenclature **Note:** Every conference uses a different system and will have different requirements. This event uses [pretalx](https://pretalx.org/). The submission form will ask a series of questions: * Section 1: General Questions * Proposal Title * Session Type * 30 min, 70 min, Fair. * Abstract * A quick summary * Description * The detailed description * Notes [private] * Note to the organisers/reviewers * Section 2: CFP Questions * Which Track? * Main, DjangoCon AU, etc * Permissions * Legal right to present * Permission to Livestream * Permission to Publish [Optional] * Content Warnings * leave blank if none apply * Questions about you * Pronouns, social media handles, self-identification [aggregated only] * Section 3: Profile Questions * Profile Picture * Name * Biography * Availability * Note: best effort. Of these questions that are asked of you, a few are important: * You have to legally be able to present the content. You also have to agree to live stream * You do not have to publish it on the internet. There have been cases in the past where the content is copyrighted, and can be shown in public, but not on YouTube. * The Notes section allows you to share things that are not public. * The Title, Abstract, and Bio are harder. ## Titles and Abstracts _In pretalx and previous conference websites formatting, the abstract is a short summary of the description. This workshop used the term "abstract" as the full description in error._ Both the title and the abstract of your talk needs to convey what's going on, but also it has dual audiences: both the group of people who review talks, and the audience. The title of your talk is going to be the first thing an audience member in a hallway trying to choose between four talks to go see is going to read, so you need to get the point across.
Proposal Titles should have: * Context * What is the context of the talk? What's the topic? * Focus, outcome driven * What will people get out of it? * It may be subtle, but there's a big differences between "In this talk, I will show you" and "In this talk, you will learn". * Intended Audience * Is it for beginners? Advanced? * Active Verbs * What will the audience be learning/doing?
Proposal titles should avoid: * Tropes and memes * These can age poorly over time, and while they may seem funny at first, they may not convey the same humour to every audience member. * Common/overused titles * If you use the same title as another talk, then people searching for your talk online may find the earlier one. * Monty Python is a decades old British comedy that has not aged well. Avoid titles based on this media. [More on the Culture of PyCon AU](https://2023.pycon.org.au/culture/) * Clickbait titles * "One weird trick" isn't going to convey information.
Abstracts should have: * Problem Statement * What is the thing that's wrong, what issue do people have? * Solution * How can someone avoid this issue? How can people solve this problem? * Learning outcomes * After seeing this talk, what will the audience member learn? * When they leave the conference, what can they try out "on Monday"?
The Notes section can have: * An outline of the talk, with rough timing breakdowns * Some events require this for all talks. Having this information will help you justify why you need a coveted 70 min slot. * Spoilers * If you want to hold back some secrets from the audience, share with the reviewers what the content is going to be about.
Anti-patterns: * Avoid "Conference Driven Development", or talking about a project or thing that won't exist _unless_ you create it as a direct result of being accepted for the talk. * "Literature Reviews", or copy/pasting from documentation/other content, is not a compelling topic for this kind of conference. * Submitting something that is highly relevant today may be out of date in the 4 months between CFP close and conference day.
Anti-anti-patterns: * Submit to talk about something you have experience, then use the time between being accepted and presenting to refine that knowledge. * Your 6 months distilled down into 30 minutes can save and audience member hours or weeks of their time. * If you aren't completely sure on what you'll cover, you can be vague. Try not to write yourself into a corner and promise something you can't deliver * If you need to drastically change your talk, let the organisers know ahead of time so they can update the information on the website. ## Biographies Your speaker bio speaks to why you are the person for someone to learn about your topic from. Bios should include: * Relevant content * Are you a Python developer? A new student? Have you written "the" book on your topic? Let your audience know! * Personality * You are more than your job. Share something that helps humanise you.
Biographies should avoid: * Self-deprecation * You should have something you'd be comfortable listening to as you are introduced on stage, after which you have to start talking * Overly long * Your employment history isn't a bio. ## Advanced Tips You can submit multiple talks! This gives the review team the best selection to choose from. _Usually_ you will only get one talk selected, unless the review team knows you can handle more than that. If you submit multiple, let the team know in the Notes section which is your preferred talk. You can submit the same talk to multiple events! Other PyCons and DjangoCons would like your content, too! Meetups like your content (and it's a great way to practise!) Your talk doesn't have to exist before you submit it! A general outline can be enough to get your general points across. You don't have to start writing slides until after your talk is accepted. Be unique! There can be many talks about [insert specific Python tool], but what makes your experience special? Did you get to apply a technique in an unusual application? Share! Accept that you may need to handle rejection. A strong conference line up are just a subset of all the submissions available, and the more submissions make for a better event for attendees. But the more submissions, the more rejections. It's not you. The event may have gotten 5 different talks on your topic, and picked a different one. It may accidentally have overlapped with the invite keynote (it happens!). You have to be in it to win it. Even if you're unsuccessful with your talk submission, come to PyCon AU! It's an amazing opportunity to meet and interact with the Python and Django community. Many people fly from all over the world to attend, and it's a great way to learn something new. There's also the world-famous 5 minute lightning talks, details as the event comes closer. See you in Adelaide!


Important in person. Not Online.

From https://2023.pycon.org.au/program/#presenting-your-talk-online

Remote presentations:
However, if you need to avoid face to face events, for example due to being
immunocompromised or unwell, please let us know as part of the submission
process. We can provide facilities for delivering your talk via a live video stream or as
a pre-recorded video.
Please note that because of the labour involved in ensuring the high A/V quality our
attendees expect, our ability to offer remote presentation slots is limited. Because of
this, we may prioritise online presenters who live in or near Australia and can’t attend
for health or disability reasons, over presenters that live far overseas and are near a
more suitable regional PyCon.
Section 1: General Questions
Proposal Title
Session type 30 min, 70 min
Abstract A quick summary of your talk. It’s your ‘elevator pitch’.
Description This is the detailed description that sells your talk to both reviewers and attendees.
Notes These will not be published, and are helpful for you to outline your talk for reviewers.
Section 2: CFP Questions
Which Track? Main, DjangoCon AU, etc
Permissions Legal right to present, Permission to Livestream, Permission to Publish*
Content Warnings leave blank if none apply
Questions about youPronouns, social media handles, self-identification (not published)
Permission to publish is optional. There are talks you can present in public but don't
want uploaded, (e.g. copyright issues. But you have to be legally able to present the
content)
Self-identification: This data is not shown to the public or to reviewers, and will not
influence your submission; we'll only use it in aggregate form to generate statistics.
Includes: ability, age, ethnicity, gender, gender identity, face, religion, secual
orientation, socio-economic status/class, learning differences, family composition,
none, prefer not to answer.
List of categories taken from the Drupal Project
Section 3: Profile Questions
Profile Picture
Name Single field
Biography About you!
Availability Note: best effort.
Out of all the questions
The hardest ones are the title abstract and bios
Outline: useful to show you've thought about this, but making it private means your
audience doesn't see it and you're not beholden to it. If you say you'll have a 7 minute
demo and you go for 5, you won't be yanked off stage.
---
Spoilers: it's okay to entice people to your talk. You don't have to have everything out
on display. It's good not to bait and switch though, so make sure the reviews know
what you're going to talk about.
For example, say you have a talk on testing. You'll want to mention you're using pytest
and whatever new extension package you're exploring that makes tests, but you can
tell the reviewer something like "I'll show the project used X on that took our tests from
30 minutes to 7 minutes (this number may improve before the conference!)
Also of note: you have to submit your talk this month. The conference is months
away. Active works in progress might change. Don't write yourself into a corner, but
don't use conference driven development
---
5: scope, problem, solution, new problems, take aways.
Hands up, discussion
Example biography: Katie
Add social media inline if no
custom field in CFP
Katie (@glasnt) has worn many different hats
over the years. Append current/relevant job title,
relation to community.
They have been a software developer for many
languages, systems administrator for multiple
Python/Django event?
operating systems, and speaker on many different Change to Python related experience
topics.
Implicit pronouns!
When they’re not changing the world, they enjoy
cooking, making tapestries, and seeing just how well Always keep this.
It's fun!
various application stacks handle emoji ✨
Give the organisers options
They will accept what they want
special message from our program chair!
You're allowed to do this!
Try this proposal at a different event!
Just make sure you check the dates and locations for the events and make sure they
don't overlap in case you're accepted to both.
If you are accepted to an event, you don't have to confirm. Pretalx calls these states
"Accepted" and "Confirmed". You can decline an invite. Conferences should always
check in with you about this before putting you on the schedule
you need to think about it a bit, but your fill slides and everything prepared doesn't
have to happen before you put it in for consideration.
you can spec it out, of course, this is useful!
but also avoid conference driven development.
Make your take on a topic unique
Vollie opportunities, student tickets etc