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 summit 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. You need to pick a place that allows people to talk freely, this means avoiding lecture halls with immovable chairs, for example. Ideally, it's fully accessible to people with disabilities as well. Most of our typical venues (universities, hotels) in the past had this, but checking with the people providing the venue up-front is a good idea.
- Plan *really* far in advance, at least 6 months.
- People only attend if you ask them to personally, and possibly only if you bother them repeatedly. The developers list is a good start.
- Invite interesting guests. Guests can be external to the project, basically users of major parts of the system. Corporate guests, i.e. developers who consume FreeBSD are an excellent choice. Warn guests that they may need to sit through hours of people arguing about obscure kernel design issues, or just find themselves in a room full of geeks tapping at notebooks and occasionally giggling due to bad jokes on IRC. Avoid marketing types.
- Make sure people think about topics to work on before they arrive. Ask people to at least submit an idea or two.
- Feed people but remember to ask in advance about dietary requirements. Vegetarian is a basic requirement in our community, but there are also kosher and other religious dietary restrictions to consider.
- Don't get stuck with the bill. Find a sponsor or tell people in advance what the cost will be. There are always cheap options.
- Make sure they have your mobile phone number and a map.
- Try to piggy-back on conference facilities.
- Require advance registration. Dev summits are usually not open to all, only to those who say they want to attend.
- Discourage guests who might just hang out in the back and contribute nothing to the meeting. This is difficult but important as you don't want people expecting a lecture because that will drain the life from the meeting.
- Have an agenda! It need not be set in stone but it must also have general areas of interest on it.
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. Breaks should be at least 15 minutes, though 20 is also good. A lot get done in the hallway track.
- 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.
- The posted daily schedule can and will change. Keep the official (probably wiki) schedule up to date as you go so people can remember what happened later on.
People get lost in new towns, your job is to make sure they find you.
- Provide specific travel recommendations such as airports, train stations, bus stations, flight numbers and whatever else you can.
- 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 and 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 (ramps, elevators, etc).
- Provide food on-site to avoid people disappearing for long periods of time finding lunch.
- Try to be near a source of caffeine. Good coffee makes happy hacking.
- 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 so working around tables is better than a lecture hall.
- 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. You can find sponsors for this kind of event.
- 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. If possible with more than just the name on them. Include a coouple empty ones for people showing up spontaneously or at the last minute.
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, and most diabetics prefer to not spend their first time in a new country touring the local hospitals.
- 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 coca 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, and check their policy on bills.
- Restaurants flexible on splitting the bill by person or by small group are preferable. Flat rates with per-person beverage bills are also fine. Avoid restaurants that will expect you to figure out who pays for what and count the money on a 45-person bill.
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.
The Place People Stay/Sleep
- Must be accessible to people with disabilities. Have one or more people who know what to watch for inspect it well in advance if possible.
- Must have networking.
- Must allow late check-in. 24 hour access is probably required given how far many people travel.
- 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. Leave space for people to add their pronouns or preferred pronouns if they want or need to.
- 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.