1. Laura Thomson
@lxt
2013-03-21

2. Overview
✤ Coming up with a talk topic
✤ Different types of talks
✤ Submission process
✤ Writing successful proposals
✤ What talk selectors look for
✤ Transforming your proposal into a successful talk!

3. What should I talk about?
Brainstorm ideas:
✤ What technologies are you familiar with?
✤ What interesting problems have you solved?
✤ What is something you know about that others may not?
✤ What are you passionate about?
✤ The ideal topic is something you could talk about to a friend for 20
minutes without slides.

4. Where should I submit my talk?
✤ It’s not quite as simple as topic -> submit
✤ Sometimes it’s see a CFP -> come up with a topic-> submit
✤ Sometimes it’s get asked to speak: fill in at a UG, talk about a project
you’ve been working on, etc
✤ Choose a venue that you feel comfortable with. If you’re nervous,
start small and work your way up. You can start higher up if
confident.

5. Talk venues
✤ Workplace brown-bag
✤ User group: these *always* need speakers
✤ Local conference: often on a single topic, may be attended by locals
only
✤ National/international conference: attracts people from all over
✤ “Big” conference: some are harder to get in to than others (OSCON,
PyCon are examples)
✤ Keynotes, TED, etc: invitation only

6. Submission and review process
Typical conference process:
✤ CFP posted
✤ Submissions must be in by a deadline
✤ Somebody reviews submissions
✤ Clear acceptances and rejections sent
✤ Second round acceptances and rejections sent

7. Types of talks
What to talk about and where

8. Technology teaching
✤ Examples:
✤ Aura for PHP
✤ Node.js in 45 minutes
✤ Focused is better than broad
✤ Who should give this talk and where?
✤ Someone who knows the topic well, at a tech-appropriate venue

9. Broader technology skills
✤ Examples:
✤ Test driven development
✤ Continuous deployment
✤ Writing secure code
✤ Typically cover a range of techniques, and can be various lengths
✤ Who should give this type of talk and where?
✤ Someone who knows the topic well, in virtually any conference

10. Vendor talks
✤ Examples:
✤ Acme Platform for App development
✤ Be careful where you submit this type of talk
✤ Many FOSS conferences do not look favorably on these submissions
✤ Some conferences have a vendor track or speaking slots for sponsors
✤ Some conferences are all vendor, all the time

11. Case studies and War Stories
✤ Examples
✤ Migrating your big data from A to B
✤ How our data center survived an earthquake
✤ Rewriting famous.com in Ruby
✤ Needs to have broad appeal: Why is it interesting? Well known?
Popular site or library? Innovative architecture or solution? Big #s?
✤ This is the perfect talk when you’ve just done something and want to
talk about it

12. Your FOSS project
✤ Examples
✤ Flask for beginners
✤ How to get started contributing to Drupal
✤ Writing documentation for the Mozilla Developer Network
✤ Who should give this and where:
✤ People who are passionate and knowledgable about a project
which has either lots of users or lots of interest, at a tech-
appropriate conference

13. State of the X
✤ Examples:
✤ State of the Onion
✤ State of PHP in 2013
✤ All those “New Features in PHP 5.4” type talks
✤ Who should give this type of talk and where?
✤ Ideally, project leads or core developers. (For smaller conferences
or user groups, could be someone else.)

14. Random stuff from left field
✤ Examples:
✤ Teaching git using toys
✤ How to build a laser
✤ A history of software failure
✤ These talks, if good, will leave people talking for weeks
✤ You have to be able to pull this off (and be able to convince reviewers
you will) - probably not a great entree into conference speaking

15. Aside: Tutorials and Workshops
✤ Talk for somewhere from 2-8 hours.
✤ Usually hands-on with exercises, coding, etc
✤ Take a lot of work to prepare!
✤ Often more incentive for the speaker in terms of travel costs,
honorariums, etc
✤ Fun! But maybe not a good thing to do first time around.

16. Aside: Panels
✤ Can seem an easy way to get started, because you don’t need slides
✤ BUT - be prepared, make notes, plan what you’re going to say
✤ Make sure you have a moderator who knows what they are doing
✤ Be clear of your role and the agenda and ideally the questions being
asked
✤ Avoid tokenism: “Can you be the PHP dev among Java devs?” etc

17. Aside: Lightning Talks and Ignite
✤ Pro: you only have to talk for five minutes!
✤ Cons: depending on the venue, these can be very competitive. Also,
it’s hard to say something interesting and valuable in five minutes.
These can be harder than you might expect.

18. Calls for Papers
What they want, and how to deliver it

19. Call for Papers
✤ Types of talks
✤ Length of talks
✤ Theme of conference
✤ Desired topics
✤ Submission process

20. Interpreting the CFP
✤ The CFP will tell you about the target audience, conference theme,
and desired topics
✤ Best tip: look at previous year’s schedules and abstracts to see what
types of talks are accepted. Study the titles, descriptions and
abstracts.
✤ Some conferences will even show how attendees rated the talks.
You might see, for example, that all framework related talks were
rated 1/5. This will decrease the chance of such talks being
accepted in future.

21. Example- php|tek
✤ PHP Community specific conference
✤ Taken from http://tek.phparch.com/call-for-papers/
✤ Currently closed (but you can start planning for next year!)

22. What the organizers want
“...we’re looking for talks that address the grown-up needs of a grown-up enterprise language, such as:
✤ TDD, Continuous Integration, DevOps or other “process”-oriented subjects
✤ New modern language constructs in PHP such as closures, traits, late static binding, etc.
✤ APIs and integration with other technologies
✤ Performance and scaling
✤ Mobile development
…and the usual plethora of PHP adjacent technologies, such as HTML5, JavaScript, Capistrano, etc., that are required to
meet the needs of serious modern sites.”

23. Fitting the CFP
✤ Does my existing idea fit the CFP? Let’s see:
✤ Automating the PHP release process - yes!
✤ How we scaled [company] to one billion users with PHP - yes!
✤ Writing games with PHP - probably not, given the enterprise focus
✤ Why Rails is still better than Symfony - maybe, hard to say
✤ Convincing your boss to use PHP - probably not

24. Example - MySQL Connect
✤ (Currently OPEN)
✤ Taken from
http://www.oracle.com/mysqlconnect/call-for-papers/information/ind

25. Key point - vendor conference
✤ “Oracle OpenWorld is organized by Products and Services tracks, and by
Solutions tracks. When submitting a proposal, at least one product or service
must be chosen from the pulldown list.”
✤ This is a (set of) conference(s) run by a vendor. Topics are related to
their products and services.

26. Aside: Tracks at conferences
✤ Small conferences are single or double track; larger ones have more
✤ Sometimes you will be asked to nominate which track your talk falls
into, and sometimes the organizers will do this for you, or generate
the track list organically
✤ In this conference CFP, the tracks are described in detail, for example:
“Architecture and Application Development: How should you architect and develop
your MySQL-based applications? What are the latest trends and best practices?
Get answers to those questions and more by attending this track’s presentations.”

27. Key points - Specific guidelines
Some are generally good advice:
✤ “Do explicitly mention what is being discussed during the session rather than
making a blatant marketing or strategy pitch. For example, include mention of
product demonstration, case study, customer/partner participation, quantitative
facts, etc.”
Some are specific to this conference:
✤ “Use present tense in session descriptions.”...”Do not use first person”
✤ “You must use the full Oracle product name at all times.”

28. Example: OSCON
✤ Currently closed for 2013 (but not announced schedule)
✤ Taken from
http://www.oscon.com/oscon2013/public/cfp/251

29. Topics vs Tracks
“Some of the topics we’re eager to see on the 2013 conference program are:
✤ How expanding one’s skills beyond a core competency makes for a better technologist
✤ Best practices for building a business around open source
✤ Innovations in user experience such as interfaces, design, and usability
✤ Cultural changes due to ubiquitous networks and computing devices
✤ Cloud computing, and openness in distributed services
✤ Geek lifestyle—hacking, productivity tips, maker culture
✤ Open web, open standards, and open data”
✤Leadership in the changing open source culture

30. Tracks (excerpt)
✤ Community
✤ Data
✤ Geek Lifestyle
✤ Java & JVM
✤ Javascript
✤ Ops
✤ Perl
✤ PHP

31. How do I interpret this?
✤ This conference takes technology specific talks, more general tech
talks, and a bunch of other stuff
✤ (That actually makes it a lot harder to know what the committee is
looking for)
✤ Again, looking at previous years’ programs is the best guideline as to
what is wanted

32. Writing your proposal
Answer the call!

33. What you need
✤ A title
✤ An abstract (sometimes)
✤ A description
✤ Your bio
✤ Sample talk (sometimes)

34. Titles
✤ Seriously, a good title will help you.
✤ The straightforward kind: “Object Oriented PHP”
✤ The obscure kind: “What I did on my summer vacation”
✤ The funny kind: “How not to release software”
✤ Title + subtitle can be a way to win at both funny and
straightforward.
✤ You need to tell people what the talk is about, and deliver that,
otherwise they will be unhappy

35. Abstracts, Descriptions
✤ Sometimes there is only one field for this, sometimes two
✤ If there are two, DO NOT USE THE SAME CONTENT FOR BOTH
✤ Try to give a brief outline of the talk. What will be the main sections
you will cover? I have seen extremely detailed outlines (down to the
minute).

36. Abstract - Examples
Practicing Deployment:
✤ “Web developers dream of continuous deployment: new code in production without a hitch. In this
talk I'll cover the full story from building deployable code through working out a build and
release process through continuous integration, automation, and continuous deployment. We'll also
look at deployment velocity and why CD might not be for you.”
How not to release software:
✤ “You've seen a million best practice talks. This is quite the opposite: I'll instruct you in the ways
I've failed over twenty years of software development, and advise you how not to make the same
mistakes.”

37. Description - Example
“Deployment can be a real bugbear for many web developers. From building something easy to deploy and manage; to coming up with a
repeatable, consistent process; to continuous deployment…deployment can keep you up at night for months on end.
In this talk I’ll cover the following topics:
✤ How to build a deployable application, from technology choice to instrumentation
✤ Deployment velocity: Why your process matters more than how often you deploy
✤ Deployment tools and processes: How to automate your troubles away
✤ CI/Automated testing: Know you’re deploying something good, or at least how worried you should be about it
✤ Automated testing vs monitoring: How they converge
✤ When are you ready to deploy continuously? How do you make the jump?”

38. Description - Example
“As your team grows and your projects become more complex, you’re going to need a certain amount of process. In this talk I’ll explain how to
add enough engineering management to be effective without driving engineers crazy. I’ll discuss:
✤ Basics of chaordic systems (or: how open source projects succeed without project management)
✤ Building trust and preserving autonomy
✤ Effective communication practices for IRC, email, and bugs
✤ The meetings you have to have, and the ones you should avoid
✤ Architecture design and problem solving in a less-structured environment
....
Attendees should leave the session with a plan to optimize their teams for developer happiness and shipping great code.”

39. Key point: enough information
✤ You need to provide enough information for somebody evaluating
the talk to make a decision as to whether it’s a good talk, and whether
it’s a better talk than the other one on the same topic.
✤ Many one sentence abstracts for perfectly good talks have been
rejected.
✤ You also need to show you have enough knowledge in the area to
give a talk on the topic.

40. Your bio
✤ Take this seriously.
✤ Unless you are a language author or similar luminary, you should
establish your credentials and why you are qualified to give this talk.

41. Example
“Laura Thomson is an Engineering Manager at Mozilla, after spending much of
the previous decade as a consultant and trainer on various Open Source technologies.
Laura is the co-author of “PHP and MySQL Web Development” and “MySQL
Tutorial”. She is a veteran speaker at Open Source conferences world wide.”
(This can be a lot longer, too.)

42. Sample talks
✤ Some conferences now ask for a video of you talking.
✤ If this is not your first rodeo, easy!
✤ If it is, need to figure out a plan. Don’t Panic!
✤ Give a lightning talk to camera - get a friend to help you. Practice!
✤ Talk at user group/brownbag and get someone to record it.
✤ Quality of video is less important than you being a confident and
clear presenter.

43. What selectors look for
(and why you might get rejected even if you do everything right)

44. Who’s reviewing my talk?
✤ Sometimes a single person, sometimes a committee, sometimes crowd
sourced. You can often find out who the reviewers are, and play to
their biases.
✤ In a multi-technology conference, they might not know why your
topic is interesting: establish this in your description
✤ Sometimes topic matter experts, and sometimes not. Cater to both in
your description.

45. It’s really simple
✤ Something the audience of our conference will like
✤ On an appropriate topic
✤ From a speaker with authority
✤ Where the submission has enough detail for us to judge that it’s good
✤ (That’s it. Really.)

46. Reasons to reject
Why don’t they like me?

47. You broke the rules
✤ You didn’t give enough detail to establish a good talk
✤ You didn’t give enough bio to establish creds
✤ Completely off topic (“Why you should switch to Ruby” at a PHP
conference)
✤ Vendor talk at an open source conference
✤ Offensive content, etc

48. Not bad, but...
✤ Doesn’t match the conference audience (too novice/advanced)
✤ Doesn’t match this year’s theme
✤ We had something like this last year and it was poorly attended
✤ “This type of talk is always unpopular”
✤ This has been done a bunch of times (especially intro talks)
✤ Nothing new here (typically well established technologies)

49. Multiple talks on the same topic
✤ We get two (or five, or twelve) talks on the same or similar topics
✤ For some reason we didn’t pick yours
✤ (Did you write a great bio and abstract?)

50. Sometimes you get Rasmused
✤ “The State of PHP in 2013” - Jane Smith
✤ “The State of PHP in 2013” - Rasmus Lerdorf
✤ This happens more often than you would expect!

51. Other reasons
✤ You behaved badly at a previous conference
✤ You were rude to the conference organizers or committee
✤ There is enmity between your project/company and the conference
organizer’s project/company
✤ Life advice: try to avoid getting into these situations in the first place.

52. Yay! I got accepted
Now what?

53. Turning your proposal into a talk
✤ Remember that detailed outline...?
✤ Each dot point/section is a section in your talk. Outline, and then fill
it out. It’s how I wrote this talk. Easy!
✤ Next talk today will cover this in infinite detail!

54. A final note for the unwary
✤ Presentation-driven development should be avoided at all costs

55. Questions?
If you think of one later:
✤ laura@laurathomson.com
✤ @lxt