Screenshot 2016-01-24 02.41.18

CFP Tips Roundup (#12DaysOfCfpTips)

On the 25th December I started a series of tweets under the hashtag #12DaysOfCfpTips. For those who are unaware, I’m one of the organisers for the PHP South Coast Conference (P.S. Blind bird tickets are up wink), and within the organising team I’m responsible for the Call for Papers and everything speaker-related in general and getting better submissions are both in the best interest of a conference organiser and the submitter.

A few people had asked me to post them up somewhere more permanent and perhaps expand on them beyond 140 characters a little so here we are with a roundup. The tweets are in chronological order.

  1. 25th December: Use the ‘extra information’ field. Say more detail, why you know about the topic, why it fits that conference.
    The extra information field is there for a reason, and whilst is often excluded in the blind rating stage, it is further information contained in this field on what the talk covers, why it fits *that specific conference* best, why you’re impassioned to speak on that topic and information on when the talk has been done before that can make a huge difference between being selected and not getting further than a shortlist.
  2. 26th December: Always get someone to read over your abstracts.  is a great place to get feedback
    The folks at help me abstract include conference organisers (sometimes the same people who will be on the panel deciding to accept your talk or not, which is a good thing by the way) and experienced speakers who know exactly what makes the kind of abstract that will get accepted into conferences. They are also good at English and will essentially act as proof-readers/copy editors for your abstract and will help catch any typographical, lexical, technical or grammatical mistakes in your abstract.
  3. 27th December: Review the talk ideas page, it should give an indication to that kind of things they are looking for
    Conferences often have themes or a target audience, otherwise every conference would end up being the same. The talk ideas page will not only indicate to you topics that the conference organisers would really like to see submissions on, they’ll also indicate who the conference is aimed at, and what kind of talks they are likely to be looking for.
  4. 28th December: Tailor your abstract and ‘extra info’ to the conference. One size doesn’t fit all.
    As per point three, conferences are different and often an abstract can be tweaked to be better suited to one conference than another for example aiming it to have lower prerequisite knowledge (which as a side note I always find more important than whether a talk is beginner/advanced as you can cover advanced topics with beginners, so long as prerequisite knowledge is low) or making the topic more in-depth and focussed.
  5. 29th December: Mention previous speaking experience in your speaker ‘extra information’ box (including UGs and Conferences)
    If looking at two speakers who have scored the same in blind rating and both have similar talk topics or both have equally well fitting talks for the conference, you will often look towards the speaker’s profile. If you see one is a new speaker who’s never spoken before living in London and the other also lives in London but has delivered a number of talks at local user groups or the talk has been well received at another conference, they become a much ‘safer bet’. Local user groups are always looking for new speakers and if you live near one or a large number of them, then contact them and ask if you could do a lightning talk or a small talk so your first experience of speaking isn’t a conference auditorium of 200+ people.
  6. 30th December: Always submit two or more talks
    Every talk you submit is another chance you might be selected and a lot of conferences might look to select multiple talks from each submitting speaker in order to minimise speaker expenses. Submitting 3 to 7 talks is perfectly okay.
  7. 31st December: Email conference organisers with questions. They’ll often be happy to advise you on what they’re looking for
    As I explained above, it’s  in conference organisers best interests to get good submissions and you’ll be hard stretched to find one who will refuse to help you with your submission. Make sure you submit to and read this set of tips first though and don’t leave it until 3 days before the CfP closes. Ask them what target audience they have for the conference, if they like your talk topics, if they have any particular topics they’d like to see submissions on (See tip 3) or even if they could review your abstract for you.
  8. 1st January: Consider your abstract a working document. It is never done until you choose to never submit it again
    If you get rejected from a conference, it might mean you were unlucky, it might mean your topic didn’t fit that particular conference, or it may indicate you need to work on refining your talk abstract and talk title. Keep working on it and improving it until you never decide to submit it to another conference. Submitting a refined version of a previously rejected talk the next year is also a totally fine thing to do.
  9. 2nd January: Keep your abstract punchy, often organisers will be looking at 200+. Keep them awake
    I think this is slightly self explanatory. Reading 200-800 talk submissions is actually really hard work and mentally tiring, you want to engage whoever is reading your abstract/talk title throughout, particularly in your opening sentence. Often the conference organisers will be the target audience of the conference as well so they’ll be judging it on how much they’d like to go and see that talk so make sure you’re pitching it at the target audience and you should get this bang on.
  10. 3rd January: If you’ve done the talk (or others) before, then include links in the extra information box
    Again, this is very similar to tip 1 and tip 5. If you have done the talk before, then let the organisers know as then they can look back at videos or ratings and see the response for themselves. If you’ve written blog articles or books or any other sort of publication on a similar topic, then be sure to include links and information about them too.
  11. 4th January: Register to ‘ CFP Report so you don’t miss any CFPs If you don’t know a conference’s CFP is open, how can you be expected to submit. This sheet is useful for an overview but the CFP report will notify you of the CFPs throughout the year. There is also CallingAllPapers and PHP CfPs twitter account both of which are great ways to keep informed about ongoing CFPs.
  12. 5th January: If you don’t get accepted, don’t be discouraged. Refine your abstract, get feedback and keep submitting!
    This is almost certainly the most important tip in this selection. Don’t give up after one rejection. Sign up to the CFP report, take a look at the other conferences you can submit and keep trying. Often it can take a year or more before being accepted to your first conference, and then you’ll spend a few years building up your speaker profile getting gradually accepted more often. This happens with experienced speakers too and you might get a dry spell of a year or so of not being accepted to any conferences. Just continue to refine your selection of talks (with friends or in #phpmentoring), work on your abstracts with the awesome people over at help me abstract, follow these tips, build up your speaker profile and experience by speaking at local PHP user groups and submit to as many conferences as you can.

After almost 400,000 impressions on that hashtag, retweets and likes from over 100 individuals and a huge positive response, on just 12 tips, I was astounded. All I can say is that I really hope that it made it beyond well known speakers in the PHP community to those potential speakers and submitters and that it’s helped. If one person was able to use those tips for a conference submission, it was worth it and if these tips helped you, then please share them.

Thanks all for helping spread the word and good luck!

The Start of Something New & Why WordPress?

Hi all,

So for the past 4-5 years now has just returned the beautiful HTML page below, and as a web developer, this was becoming rather unacceptable. It is made worse by the fact I actually tell a lie in saying ‘this should only take me a few weeks’ as while this was my intention at the time, I never quite got around to it in that timeframe.

Screenshot 2016-01-10 13.58.22

For a while now I’ve also been making repeated comments in tweets, on mailing lists and in pull requests on topics that I feel more expansion is needed, at least significantly more than is traditional on those mediums of communication. I’m also not a fan of typing out the same arguments again and again. Recently there have also been a few things I’ve wanted to make comments on and one of my new years resolutions this year was to finally get a blog (Another one is write at least an article a month for this blog or elsewhere but we’ll have to wait until December to see if I achieve that one). I’ve got a (physical) list a mile long of topics to blog about including posts on community, OOP, open source culture and Computer Science (The more maths-y bits).

So, here I am, with a website at last. I’m not sure how I feel about the design. I wanted to go for something more like Impronta but I couldn’t find any appropriate images, but I might look to change this in the future if I feel like it’s worth investing time in this site. Let me know if you think anything looks crap.

Many of you will notice I’m using WordPress (and those who haven’t should guess by this article title), and the number one question I’ve been getting is why use WordPress (WP) and not Jekyll or Sculpin. My answer is a simple, one. Simplicity. In the creation of this site, I’ve not had to touch a line of PHP (This is a new web server setup with PHP 7 though because PHP 7 rocks) or run one command line script; I’ve not done anything even vaguely complicated at all. I’ve committed this site to git and pushed it to a private repository on my personal gitlab install as a backup of the file system but otherwise, it’s just a standard WP very consumer type install. I’ve also used the built-in UX tools such as the plugin manager and automatic updater scripts. WordPress gets a lot of flack, but ultimately it provided a simple solution to what should be a simple problem, WP allowed me to get a site up and running with little effort, stress and time.

In the future I might change this site to something using markdown articles (I’m using markdown syntax to write these blog posts as WP supports that) and Sculpin or Jekyll as the parser but for now, I think I’m quite happy having a WordPress site. For all the flack that WP gets in the PHP community, we should all remember is that it does serve its primary purpose well. It is an easy to use blog software which makes thing simple and easy for end-users and consumers who need simply solutions. I’m not going to extend that statement to sites with larger needs, enterprise scale sites or sites looking to use WordPress as a CMS, as I’ve never tried it in those contexts or dug around in WordPress’ codebase (I’ve heard plenty about all three of varying opinions), but I stick by what I have said.

So, here’s to more blog posts I guess.