How to organize a DevSummit

Organizing a FreeBSD developer summit is not very difficult, as it mostly involves piggy-backing on an existing conference or event and borrowing their facilities. However, there is some hard-earned experience that is worth taking into account, because the success of a developer depends a lot on avoiding the logistics distracting everyone from getting work done. This wiki page tries to capture a few points worth remembering when running a devsummit.

• Choice of venue is critically important to the dynamic of a devsummit.
• Plan *really* far in advance.
• People only attend if you ask them to personally, and possibly only if you bother them repeatedly.
• Invite interesting guests.
• Make sure people think about topics to work on before they arrive.
• Feed people but remember to ask in advance about dietary requirements.
• Don't get stuck with the bill.
• Make sure they have your mobile phone number and a map.
• Try to piggy-back on conference facilities.
• Require advance registration.
• Discourage guests who might just hang out in the back and contribute nothing to the meeting.

Plan well in advance–people will be coming from all over the world, and they don't want to pay 2x the airfare because you were lazy.

• It is *very* important to set the dates far in advance, ideally at least two months so that discount airfare is available.
• It is *very* important not to change the dates later.
• Aligning with conference tutorials is useful – you can borrow space at the venue, piggy-back on discount room rates, and while developers sometimes teach tutorials, they rarely take them.
• Don't start before 10:00am, don't finish after 6:00pm.
• Don't spend more than 8 hours in one room. Really.
• No more than 2 hours between breaks. Really.
• People often skip breakfast, so serve lunch by 12:30pm.
• Recommend specific travel dates to avoid lots of late arrivals.
• Organizers should provide their mobile phone numbers well in advance.
• Provide travel information, including printable maps, before people start traveling.
• Plan for people reading e-mail for the first 20-30 minutes before starting, some will have been offline for a few days and discovering that the world has collapsed.

People get lost in new towns, your job is to make sure they are found.

• Provide specific travel method recommendations.
• If there is more than one airport, say which is the best.
• FreeBSD developers like trains a lot for reasons of mixed quality.
• Recommend specific travel dates.
• Provide easily printable maps.
• Provide easily printable directions.
• Make sure people have your mobile phone number.
• Someone will always have to leave early due to an emergency – plan ahead for this eventuality.

Choice of venue is one of the most critical decisions you will make. Some points in no particular order:

• One of the organizers must be local to the venue. This is really important.
• Pick a venue physically close to where people are staying (<30 minutes walk). Don't require taking a bus.
• Make sure the venue is wheelchair-accessible.
• Provide food on-site to avoid people disappearing for long periods of time finding it.
• Dynamics of a meeting are determined by the layout of the space.
• If you want people to talk to each other, they have to be able to see each other.
• If you want people to pay attention to a talk, they need to be able to see the speaker and the screen.
• Overhead projectors are really useful for reading code and looking at pictures.
• White boards are really useful for taking notes and drawing pictures. Whiteboards require markers, so bring some.
• Having multiple rooms helps.
• Auditoriums/lecture theatres with fixed seating are terrible for conversations and presentations.
• Notebooks benefit from tables to put them on, and power to plug them into.
• Provide 100% network access or 0% network access, but whatever you do don't provide 15% because then people waste hours trying to make it work.
• Sunlight is a good way to keep people awake.
• Chairs and tables are great during the day, but sofas, beer, and 802.11 are better in the evenings.

Experience suggests that movable chairs and tables with a projector and whiteboards makes the best venue, and that these can be surprisingly hard to find on the campuses of so-called universities. Why is this? Hard to say, but it sucks.

• Try not to get stuck with the bill.
• Do not collect money at every meal.
• Charge a fee to attend, require advance payment or payment on arrival.
• Accept only local currency.
• Make eating depend on paying.
• Try to avoid getting in the loop for people paying for residence; sometimes unavoidable, but it means much more money goes through your hands.
• If moving a lot of money, carefully separate devsummit finances from personal finances – different bank accounts, etc.
• Never trust the American banking system to do anything right.
• Anticipate banking fees by including it in any rates.
• If you need funding from the FreeBSD Foundation, apply well in advance.
• Advise attendees needing financial support to apply to the FreeBSD Foundation well in advance.
• Be sensitive to attendees on the wrong end of a weak currency and students without salaries.

The people at a devsummit are what make it work.

• Invite people personally.
• Bother them when they fail to reply.
• Help them figure out how to get there.
• Make them think about what they want to talk about in advance.
• Thank them for coming.
• Invite guests from outside the developer community – especially people who can provide a new view on an important topic.
• Introduce guests.
• Provide name tags.

Developers think with their stomachs, so keep their stomachs happy. Nothing breeds discontent like soggy sandwiches and bad coffee.

• Bringing in food is a good way to avoid losing everyone for two hours in the afternoon.
• Charging in advance is a good way to avoid screwing around with money or getting stuck with the bill.
• Don't go the same place for dinner every night, or ideally more than once in a conference/devsummit.
• Pay extra to get better food, people whine less.
• Don't forget sugar-free beverages – diabetes is not uncommon.
• Ask people to tell you in advance if they have special requirements, and get extra vegetarian meals.
• Over-cater by 20%, hackers eat too much.
• Afternoon snacks are good.
• People drink a lot of coka cola, a lot of coffee, some tea, some sprite, and none of the other stuff.
• RobertWatson prefers hot chocolate to coffee.
• If the residence doesn't provide breakfast, you must provide it. You may want to do this even if the residence does provide breakfast.
• Do headcounts for dinner in advance.
• Make it easy for the group to go out to dinner together.
• Restaurants require reservations for large parties.

All work and no play makes Jack a dull boy, and burns people out.

• Plan to go out to dinner somewhere nice with a bit of a walk to clear heads.
• Leave a gap between formal events and dinner so people can drop off bags, etc.

• Must have networking.
• Must allow late check-in.
• Check to makes sure they didn't screw up the bookings, this is common and really annoying. Check again.
• Provide information packs, including maps, in advance electronically, but also leave paper copies at the residence.

• Name tags are really useful, especially if you have guests joining the community for the first time. Names should be no less than 20 point.
• Get to the venue before the developers to avoid wasting everyone's time setting up projectors.
• Bring extra power strips.
• Don't provide a document for printing that relies on links to other things to be useful.