- Ashley
- Jorge
- Ricky
- Manish
Before you review talks, have a clear idea of what your target audience is. This is not just “users of the technology the conference is about”, this is also includes subgroups by field or level of expertise. Beginner talks will bore advanced users, and advanced talks might not be useful for beginners if it is at too high of a level (but might also inspire them). When you have multiple rooms, having multiple targets is more feasible; however this can be tricky to schedule, so be careful.
If you have an emcee (MC), be sure to communicate with speakers about this well in advance. Ask how they’d like to be introduced — some may provide you with text, some may care less (in which case, prepare the text yourself and make sure the emcee has it well in advance). Make sure you know their pronouns, and have your emcee work with them to make sure their name will be pronounced correctly.
Some speakers feel awkward about self-introduction, so having an emcee introduce them can be quite helpful. Others may have a talk that starts with an introduction that segues into the material, so they may wish for the emcee introduction to be shorter.
Overall, be consistent with how folks are introduced.
A website or central document that describes the general practices and layout of the event is very valuable and can eliminate a lot of redundant questions.
Try to keep all the information for the event in a central and logically organized manner. Keep in mind that weird things will happen so have a plan for emergency/urgent announcements (anyone have an HDMI cable?) and make sure people know where to look for these. Use the same medium (twitter/Slack/IRC/etc) as inconsistency will lead to confusion or missed announcements.
Visit the venue at least once before the event, and prep the volunteers on the basics (especially if they are also coming in from out of town).
Although we “know” that things take time, we rarely schedule time for all the things, beyond talks, that need to happen during an event. Some of these things include:
- Applause (seriously)
- Plugging/Unplugging Laptops
- Speaker Introductions
- Announcements
- Sponsor talks (and other house-keeping)
In order to realistically design your program, you should specifically set aside time to account for these things. We recommend:
- 10min at the beginning and end of the program day
- 5-10min between talks
These times serve 2 purposes:
- realistically set time aside for things that have to happen and things take time
- You can use this time to recover speakers going over and under!
You should not only set this time aside but you should clearly show it on the program you display and distribute to attendees. They appreciate a realistic schedule and will be more likely to comply with it if they know when it is and why it’s there in advance which always makes things run more smoothly.
It is extremely useful to have your A/V or organizers available to help speakers set up their machines on stage to test their display before they have to speak. Inevitably, not every speaker will be available (and some will flake out and forget) but every person you are able to tech check saves you time in your program and also allows the event to appear more professional.
We are all developers for the most part, and are aware of how computers are terrible and never work. Nevertheless we are an unforgiving group when it appears that people have not prepared for or are surprised that computers.
Checking on equipment during breaks (coffee, lunch, etc) is a good way to make sure the equipment is still functional, or a good time for repairs.
You should decide if and how you will have Q&A after the talks. There are multiple formats you can choose:
- Don't have a Q&A after the talk, instead ask attendees to approach the speaker in the breaks
- Have a microphone for the audience for immediate questions afterwards
- The MC should be around and stop people without an actual question
- If no audience microphone is available the speaker/MC needs to repeat the question (to capture it for recordings/livestreams)
- A moderated Q&A, where questions have to be submitted to the MC, who will ask them
- Collect from Twitter, IRC channel, etc. or dedicated website
- If the event is livestreamed a "no presence required" way of asking questions is appreciated
Ask applicants for the kind of audience their talk targets. Are their audience beginners, intermediate or advanced users? How technical is their talk?
The program should try to balance the talks to not overwhelm the beginners and to not bore people familiar with the language with details they already know. Some possible ideas here:
- Have two tracks running in parallel: one for beginners and one for intermediate / advanced users.
- Another option is to schedule the beginner talks at the beginning so the that part of the audience feels more confident to attend the more advanced talks.
Be aware of the human limitations of your participants! People get sleepy after lunch, or they may be hungover on the second morning of the event. An idea here is to have more technical talks after the coffee break and less tech heavy talks after lunch and on the second morning of the event.
Can depend on the equipment a the venue (e.g. 1 Coffee machine for 100 people?)
There’s a trade-off here: too many breaks can stall the momentum of the talk, but there need to be enough breaks as to not tire the audience.
If you have extra time before and after talks for tech setup and as a buffer for avoiding a talk overrunning into other we suggest you indicate in the schedule that those times are for that and are not breaks to get coffee.
Breaks are also good for the "hallway track" type discussion so factor those in to allow for great discussion and collaboration.