Not to be a downer, but that "free" trip you got by having your conference talk accepted is pretty far from free. TANSTAAFL, and all that. Here some additional "costs" you may have to consider. (Organizers: think about the huge commitment your speakers are making when they agree to speak. Try to make things as easy for them as possible.)
- Time off. Some companies are happy to consider conference-attending as work days. But if your company isn't, or if you're self-employed or a student, or have already done a lot of speaking this year and your company can't really cover any more, then you'll be using your PTO or otherwise covering these days yourself.
- Travel costs. Even if the conf offers reimbursement for travel costs, most do so within a few days of the actual conference. If that's the case, you're going to have to float the money until the paperwork and funding goes through. And unfortunately it's not uncommon to have to "remind" the organizers to process the reimbursements. This can be reduced by having the conf book (and pay up front) for as much as possible, but not all confs offer this and this isn't an option if you're traveling with a SO and want to sit together on the plane.
- Travel hassles. Travel can suck, particularly if you're going via airplane. Your odds of encountering that suck increase with every layover and international border.
- Eating. If you're traveling, you'll probably be eating out. There is almost never a per-diem covered by community conferences, so be sure you've budgeted for your food. Also consider any tourism costs if you'll be combining the conf with a few actual vacation days.
- Talk preparation time. How much do you value your time? Somewhere between minimum wage and your hourly rate? If you have a talk accepted, your new hobby is preparing that talk. Writing and researching and coding demos and practicing in front of people. Some magicians can write a 25 minute talk in 3 days. I sure can't. My talk preparation is like water in a pothole - it expands to fill all available time and space.
- Partner time. If have a partner traveling with you, odds are they won't attend the conference with you. But you'll probably plan to spend time with them; perhaps dinner each day and a few days touring after the conference. Be sure to work this all out ahead of time so that all expectations are met.
Way back in 2013, I decided that it would be good for my professional development to attend some conferences. I had just started a new job, with some savings left over from unemployment time, and so I had some budget to attend conferences on my own dime. I had met Carter Rabasa (founder and long-time organizer of CascadiaJS) by attending the SeattleJS meetup in the previous year. So I arranged a trip to Vancouver, BC for CascadiaJS in November. On the Hacker Train up from Seattle to Vancouver, I met Tracy Hinds, who had organized the Hacker Train all the way up from Portland.
CascadiaJS 2013 was an absolute blast. The talks were interesting and educational, and I met a bunch of new (and now long-time) conf-friends and even got mistaken for a speaker! I followed new friends on Twitter, and CascadiaJS on Github. Not too long after coming home, I wrote up and posted some of my notes and published them on this blog. I knew I would be ready to do it again in 2014.
And I did. CascadiaJS 2014 was in Portland, and I bought a ticket and lodging nice and early. Beyond being excited about attending, I had even begun to think I might be able to speak. I had even submitted a talk. It was pretty awful, but that's the first step. 2014 was just as wonderful as the last year - I made sure to thank Tracy and Carter (head organizers for that year) personally, since I knew it was a ton of work to organize something so big and so lovely. (Organizing a conference is kinda like organizing a wedding, once a year.) Since I followed the CascadiaJS repo, I was able to observe many parts of the organization process, and contributed some (hopefully!) helpful thoughts for the next year.
So, there you go. I got involved by attending first, providing useful feedback to the organizers, and participating in the community.
Bottom line - your events (from meetup to conference) and even your open source projects need a code of conduct. What is a code of conduct?
- It is an explicit statement about what is - and isn't - appropriate in your space. It sets a social contract that every attendees agrees to, and encourages active enforcement of that social contract.
- It is a promise from you (the organizer) to me (an attendee or speaker). If you break that promise, I am 100% free to leave your project / event without any repercussions.
- It compels a response, even when the organizer would rather ignore a situation.
Let me tell you precisely how a code of conduct works to change interactions during an event.
Last year, I attended a conference as a workshop volunteer. After the workshop, a speaker from the previous day wanted to ask me some follow-up questions about the workshop. While he spoke a little English, he wanted me to step outside to the plaza where his translator was. I agreed.
Let's review the power dynamic here: me = unimportant volunteer, him = very important speaker.
He was from a country where (I suppose), it's common for men to escort women by leading them by the elbow. While we were walking outside, he put his hand on my elbow, and I (being perfectly capable of finding the doors outside) removed it. He again put his hand on my elbow and tried to lead me towards the door. I again removed it, and looked him directly in the eyes and said "no". I then stomped through the doors and found the translator. With the help of the translator, the speaker apologized if he had offended me. I said that I was fine and I answered his questions from the workshop.
Here is how the conference's code of conduct worked: I knew that - regardless of any power imbalance - the conference had my back. I was empowered to enforce my own boundaries and I did so. I was a bit irritated by the incident, but I took care of it myself. Situation resolved, no escalation, no problem. That's how a code of conduct works.
I'm curating CSS Day at CascadiaFest this year, and earlier this month we finished our speaker selection process. Since I've evaluated hundreds and hundreds of proposals for CascadiaFest, I thought I'd share what I'm looking for when I evaluate a talk proposal. At CascadiaFest, our selection process is masked; we do most of the evaluation before revealing the identity of the person who wrote the proposal. (Though it's sometimes possible to guess who has submitted the talk.) Naturally these thoughts are only about my process, and do not represent any other curators or selection committee members.
Does the proposal give me a sense of what you'll actually be talking about on stage?
Screen writers are often told "If it ain't on the page, it's not on the screen." Films and plays often follow the advice to "show, don't tell". Once I watched an episode of "Next Food Network Star" (or something like that) and the experienced host gave this advice to the contestants: "Don't describe the food as 'delicious', 'yummy', or 'fantastic'. Use words with meaning like 'chocolaty', 'tender' or 'flaky'."
All of these ideas apply to writing talk proposals too. I'm not going to infer things that you haven't mentioned in your proposal. Don't tell me that you're an awesome speaker; show me with previous talks. Use words that are clear and descriptive.
Pretend your reviewer is on an international flight with no wi-fi, and can't look up "polymorphic". (True story.) No one should have to read 3 articles to understand the core concept of your talk - you should be explaining it.
Does the proposal convince me that you can pull this talk off? Does it demonstrate knowledge of (or passion for) the topic? Don't rely on a bunch of keywords and memes in your proposal; tell me about your history with the topic, or the insights that you've had.
Can you expand on the techniques you intend to discuss? How will your solutions stand out from others in the same space? If your proposal asks some questions, include some answers to those questions to demonstrate that you've got a useful perspective on the topic.
Does the talk proposal boil down to "Getting Started with XYZ" where XYZ is some framework or tool? These talks have their place, but I'm really not a fan of them. I look at how relevant your talk will be to people who are not using that framework, because the majority of the audience at CascadiaFest is not using your favorite framework.
Use your very best written English. Organizers often see that the care taken in writing the proposal reflects the care taken in preparing for the talk. Get someone else to proofread your proposal - buy dinner for your friend with the snootiest grammar sensibilities, or exchange proofreading duties with someone else submitting a talk. Proofreading your own talk is just as difficult as security-testing your own software.