Talk proposal get_accepted

516 views
441 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
516
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Talk proposal get_accepted

  1. 1. Laura Thomson@lxt2013-03-21
  2. 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. 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. 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. 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. 6. Submission and review processTypical 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. 7. Types of talksWhat to talk about and where
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 18. Calls for PapersWhat they want, and how to deliver it
  19. 19. Call for Papers✤ Types of talks✤ Length of talks✤ Theme of conference✤ Desired topics✤ Submission process
  20. 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. 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. 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 tomeet the needs of serious modern sites.”
  23. 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. 24. Example - MySQL Connect✤ (Currently OPEN)✤ Taken from http://www.oracle.com/mysqlconnect/call-for-papers/information/ind
  25. 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. 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. 27. Key points - Specific guidelinesSome 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. 28. Example: OSCON✤ Currently closed for 2013 (but not announced schedule)✤ Taken fromhttp://www.oscon.com/oscon2013/public/cfp/251
  29. 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. 30. Tracks (excerpt)✤ Community✤ Data✤ Geek Lifestyle✤ Java & JVM✤ Javascript✤ Ops✤ Perl✤ PHP
  31. 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. 32. Writing your proposalAnswer the call!
  33. 33. What you need✤ A title✤ An abstract (sometimes)✤ A description✤ Your bio✤ Sample talk (sometimes)
  34. 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. 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. 36. Abstract - ExamplesPracticing Deployment: ✤ “Web developers dream of continuous deployment: new code in production without a hitch. In this talk Ill cover the full story from building deployable code through working out a build and release process through continuous integration, automation, and continuous deployment. Well also look at deployment velocity and why CD might not be for you.”How not to release software: ✤ “Youve seen a million best practice talks. This is quite the opposite: Ill instruct you in the ways Ive failed over twenty years of software development, and advise you how not to make the same mistakes.”
  37. 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 arepeatable, 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. 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 toadd 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. 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. 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. 41. Example“Laura Thomson is an Engineering Manager at Mozilla, after spending much ofthe previous decade as a consultant and trainer on various Open Source technologies.Laura is the co-author of “PHP and MySQL Web Development” and “MySQLTutorial”. She is a veteran speaker at Open Source conferences world wide.”(This can be a lot longer, too.)
  42. 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. 43. What selectors look for(and why you might get rejected even if you do everything right)
  44. 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. 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. 46. Reasons to rejectWhy don’t they like me?
  47. 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. 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. 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. 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. 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. 52. Yay! I got acceptedNow what?
  53. 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. 54. A final note for the unwary✤ Presentation-driven development should be avoided at all costs
  55. 55. Questions?If you think of one later: ✤ laura@laurathomson.com ✤ @lxt

×