Giter Club home page Giter Club logo

lessobviouschecklist's Introduction

The Less Obvious Conference Checklist

This is a checklist for conference organisers of less obvious things. It’s easy will remember to book a venue, look for speakers and sell the tickets, but you could overlook many small things that can help your conference stand out. I mainly compiled this list from my own experience and from what I’ve seen other conferences do. So although I compiled the list, many recommendations are the result of hard work of others. See the AUTHORS file for a more extensive attribution.

This is not a checklist of things you must do in order for your conference to be any good. Or a list of requirements for me to do something for your conference. Consider this more as a list of actionable and practical suggestions to help us make better conferences. Don’t feel bad if there are many that you can't do: I don’t know of a single conference that follows every suggestion from this list - not even the ones I organise myself.

Something is missing / I disagree

This list is almost certainly incomplete. If you have any suggestions, open a pull request. And if we can’t come to agreement, you can always start a fork :)

This work is licensed under a Creative Commons Attribution-ShareAlike 2.0 Generic License.

Contents


Inclusivity

  • The importance of inclusivity is becoming well known in most communities. In general, remember that inclusivity is not exclusively about gender.
  • If you are running a financial aid program, I wrote about some common issues I see.
  • For events involving alcohol, help people who do not drink feel welcome. Mention non-alcoholic drinks as often as alcoholic drinks, make them equally visible and have an equal number of options. People who don’t drink alcohol should not have to justify themselves. This article has many more great practical tips.
  • If you are providing food, ask people in advance (during ticket registration, for example) about any preferences / allergies. This doesn’t mean you must cater to every possible option, but often a lot is possible.
  • Be mindful of how you identify the geographic region for the conference. DjangoCon Europe is notably not DjangoCon EU, because EU would mean we can’t have one in Switzerland. Communicate consistently on this.
  • Be very careful in how you describe your target group. If you use phrases like “advanced developers”, many people will not attend because they won’t feel advanced enough, or because they feel more like tech writers than developers. Also be mindful of terms like technical and non-technical.
  • Make transgender people feel more at home with posters stressing attendees shouldn’t judge who is using which bathroom. There might be legal issues with doing this in some countries.
  • Look into making non-binary people feel more at home with explicitly gender-neutral bathrooms. Don’t replace all gendered bathrooms though. This may also be helpful for parents and for other trans people. If your event uses multiple floors, you could mark bathrooms on some floors gender-neutral. Another option are separate wheelchair accessible bathrooms for this, which are generally gender-neutral already, by explicitly marking them as available to non-binary people too. Few events have such a high ratio of wheelchair users that this creates capacity issues.
  • In registration, ask people for their preferred pronouns. Most people will probably prefer the pronouns that match their apparent gender, but this really can make a difference to trans and non-binary people.
  • Whenever you ask for people’s names, don’t ask for a first and last name. Not everyone has a clear first and last name, and there is little reason to want to separate them. When you ask for names, ask how they would like to be called in a single field. If needed, add a separate field for their legal name. You’ll probably need the latter if you are making hotel reservations for people, for example.
  • Some people, especially those new to attending events, may be uncertain about the dress code. It’s worth specifying this explicitly, even if your entire dress code is “wear whatever you’re comfortable with, as long as it does not violate the code of conduct”. PyCon UK 2016 does this very well.
  • Some ways to improve inclusivity may seem odd or useless to you as organisers. However, they can often make a big difference for other attendees in different positions and from different backgrounds, at little cost to you.
  • Promote your event towards relevant groups early and often, preferably from the moment of announcement on. This avoids rush action to "fix" a less diverse attendance/speakers roster.

Accessibility

  • Write an accessibility statement. I wrote one for Django Under the Hood. In this statement, you inform people with physical, visual or auditory impairments what you can offer them. This doesn’t mean your conference must be accessible, and if it’s unavoidable it’s ok to say you don’t know. It’s most important role is that you inform people what you are planning to do, what you do and don’t know, and that you’re happy to listen to anyone’s questions in this area.
  • Provide the simplest way of access for inquiries - an email address. Forms and too many detailed questions might be inaccessible and/or put people off.
  • For people with physical impairments, be specific about the actual situation. Some people that use wheelchairs can actually cross a few steps if needed. Some require specific accessible toilets, others do not. A generic term like “wheelchair accessible” leaves many questions for these people.
  • Don't forget to check and document the acccessibility of social event and dinner venues.
  • Try to get hold of a portable ramp. It helps fix tiny inaccessible areas in the venue, in case you have forgotten some.
  • For people with auditory impairments or simply non-native English speakers, consider having a captioner/stenographer. This can also be incredibly helpful for non-native speakers, and means you have a written and searchable record afterwards. This was done at !!Con, who wrote about how well it worked out for them. Recent European Django conferences adopted this too.
  • In signage, lanyard colours and badge design, be mindful of those with color vision deficiency (commonly called color blindness). A good tool to test this on Mac OS X is Color Oracle.
  • It’s easy for people to feel overwhelmed by the social interactions, sound level and business at conferences. A quiet room, which is a (somewhat) noise insulated room where there is no talking, can give these attendees a chance to decompress. It’s also a good place for people that need to focus on some work. All you need is a room with some chairs/desks/beanbags. Make sure that your quiet room is in a place that's easily and discretely accessible.
  • Similarly, you can also consider to have a separate prayer room.

Code of conduct

  • Have a code of conduct / inclusivity policy. There are plenty of examples for this. Most of them can be summarised as “don’t be an asshole, and be considerate for how your actions may be perceived by others” but for numerous reasons that have been discussed at length elsewhere, it is important to include more detail.
  • Ensure the CoC is known to everyone. This ensures nobody can say “I didn’t know” and also stresses to your attendees how important it is to you. Make people confirm knowing the CoC when they buy a ticket, or submit the call for papers. Have posters around the venue with a short version and mention it in your introduction talks every day.
  • Parties are notorious for CoC violations, often related to alcohol. Stress in your announcements by mail, twitter or in person, that the CoC applies to the party too. When you make your event more accessible to people that don’t drink alcohol, as listed above, you are also making it easier for other attendees to drink moderately and responsibly. People are more inclined to keep drinking more if everyone around them is still drinking alcohol too.
  • Your CoC is useless if you can not respond to issues. Set up a CoC team. In DjangoCon Europe, they’re called CoC Active Response Ensurers or CARE. An ideal size for this is four people: two men, two women. These people are the primary responsible persons for dealing with any reports, and should be able to have their hands free at any time. They can involve other team members if needed, but having a small CARE team makes it easier to respond consistently, professionally and timely, without distracting the rest of the team.
  • Have special phone numbers available for reporting CoC issues, especially for emergencies. DUTH and DjangoCon Europe use two phone numbers: for a male and female organiser. We buy prepaid sim cards in the country of the conference, and put these in cheap dumb phones. Two members of the CARE team carry these the entire conference. The numbers are on posters, the conference booklet and the website, and their availability is mentioned in the opening notes.
  • The primary reporting mechanism is probably still email, so have a [email protected] available and communicated that goes to the CARE team.
  • If you have a Slack or twitter hashtag, don’t forget to monitor those for CoC issues. Consider also using highlight words to notify your CARE team when an abusive term is used, or when someone starts a conversation about harassment or the Code of Conduct. (Remember to include common misspellings.)
  • You or your community may be hesitant to adopt a CoC, for example because it feels to some as a tool of censorship. Issues where someone’s behaviour is so unacceptable that they are removed from the conference, or even the community, do occur. However, many issues are much less serious, and more due to someone being unaware than of ill will. They still require careful handling, but that could also be a serious conversation of “you did this, this isn’t cool, don’t do it again, have a nice conference”.
  • To build further support of a CoC, publish a transparency report afterwards. We first published one for DUTH 2015. Ensure nobody in there is identifiable.
  • You can consider screening the presenters’ slides in advance for CoC violations. This is some effort in advance, especially because not all speakers will be able to send you their slides early. A draft version might also suffice. The point is that you can catch at least some possible CoC violations before they’re shown in the large screen in front of all your attendees. You can also use this to check for readability issues like contrast (especially considering color vision efficiency) or size.
  • Do not underestimate the energy it will take from the CARE team to deal with issues. Ola Sendecka wrote about this for DjangoCon Europe 2016.
  • Never assume you don’t need a CoC because nobody reported any issues, and therefore you don’t need one. As Ola notes, it takes time for people to feel comfortable to report issues. And not having a CoC at all is sending a very strong message to everyone that reporting isn’t worthwhile.

Making attendees feel at home

  • In general, use all your communication to make attendees feel welcome. At Django Under The Hood, we had posters with “Yay, you made it!” on all the entrances. Even minor touches like that can help create a good atmosphere at your conference.
  • Basic bathroom supplies are much harder to find in an unknown country and area. At DUTH 2015 and DjangoCon Europe 2016 there were boxes near the bathrooms with items like toothbrushes, ibuprofen and hygiene products, free to take as needed by all attendees. It makes people feel a little more welcome.
  • The city where you’re holding your conference is probably well known to you. This is not the case for most of your visitors.
  • Help your attendees find their way around by writing something about travelling to and around the conference. Here’s what I wrote for Django Under the Hood. Which airport should people go to? How do they best get to the city? How do they get from hotels to the venue? Can I buy transit tickets with a credit card? Do I need a visa? Is there a nearby supermarket?
  • Check local news for local events, construction sites or weather warnings that might impact the attendees' travel to the venue. Communicate these to your attendees to help them navigate it.
  • When picking a date for your event, check a calendar such as interfaithcalendar.org to be aware of any cultural or religious holidays that may be outside of your direct awareness.
  • Help attendees stay near other attendees. As soon as you know, tell people what the speaker hotel will be, so that others can decide to book there as well. Publish a few recommendations of alternatives, ideally with varying budgets.
  • In your program, be clear on what food you’re providing. Some conferences offer breakfast at the venue and then forget to tell attendees, which will then already have paid for hotel breakfast. The other way around also happens.
  • Many communities have in-jokes and amusing traditions. There’s nothing wrong with that, but it can make first-timers feel more alienated. You can reduce this by publishing a glossary of some of these things.
  • Don’t publish attendees’ info on an attendee list or something similar, without them opting in.
  • Make sure the organisers are visible. If you have a registration desk, try to have someone there all the time. If an attendee needs help, it can make them feel very lost if they can’t find an organiser.

Children

  • Consider offering childcare, to make the event more accessible to parents. PyCon has done this in the past. You could poll whether attendees might be interested, and see if it would be affordable for the parents. Perhaps one of the parents would even be happy to volunteer to help with preparation work. There can be legal requirements involved.
  • If many of your attendees travel longer distances, the travel costs for a child would still be substantial for the parents, and it would take them extra effort and planning. Therefore, another option is to offer to cover costs of childcare at home. If most of your attendees are local, this is less of a concern.
  • In general, be explicit about whether children are welcome at your event and in which settings, and which kinds of food you can provide for them.
  • Some attendees may need to breastfeed or pump breastmilk. The best is to have a space planned for attendees for this purpose, and document who to make space requests to. Ideally, this space would be near the childcare room.
  • A nursing parent at a conference will likely need to nurse/pump 1-3 times between 08:00 and 18:00 in 30 minute blocks of time (between setup, pumping, and cleanup). At a minimum, the space just needs to be clean, private, and have electricity. Include access to a refrigerator or mini-fridge if that is an option. Most event spaces (or HR departments, if the event is in an office space) are used to handling these sort of inquiries.
  • If you are planning an event for women and may have many attendees who need nursing/pumping breaks, build in longer mid-morning/afternoon break times (30 minutes).
  • Be explicit in that the private breastfeeding room is an optional service, and that feeding is allowed wherever and whenever the attendee likes. Otherwise attendees may think this is only allowed in private spaces. The private space is still needed, as some attendees may be more comfortable in private, and not every child will nurse near noise and traffic.

Speakers

  • Be clear on what’s in your speaker package as soon as you open the call for papers. Personally, I rarely speak at events where travel and stay are not covered by the conference, but others may make other decisions. But they can only do so if you inform them.
  • If you are doing a call for papers, also send it to minority groups in your subject. If it’s a Python conference, contact your local and the global PyLadies chapter, and ask whether they can recommend any other minority groups whose participants may be interested in submitting a proposal.
  • Have your code of conduct up on the website before sending out your call for papers.
  • Conferences and communities benefit from having a good mix of experienced well known speakers, and less experienced speakers. For the latter, it can be helpful to offer some basic coaching, if only by looking over their slides, to help improve their sessions and their confidence. Perhaps there are open speaker coaching groups in their hometown that can help them, like Appsterdam’s monthly speaker training meeting. Perhaps some of your more experiences speakers can help out. If you’re willing to help with this include it in your call for papers, so less experienced speakers feel welcome, confident and supported.
  • Ensure that all your speakers are familiar with your code of conduct.
  • Ensure you get the details of the sessions right. A good way to do this is to mail all speakers a week in advance (or at least before any print material is produced) confirming the times, locations, titles and abstracts of their sessions. Also useful to include: when you expect them to be at the venue at the latest, whether they should report anywhere specific, the details of their flight and hotel if applicable, and what technology you have available (beamer, adapters, connectors, etc.).
  • Remember to get all your speakers a modest speaker gift at the conference, regardless of the size of the speaker package.
  • Some people strongly prefer to share a hotel room with someone, others strongly prefer a private room. If you arrange hotel rooms for your speakers, you can always ask whether anyone would like to share. This works particularly well when many speakers know each other already. Sharing rooms reduces your costs. Do ensure that you always keep the option open for people to have a private room, without extra cost, for those that need the personal space or need a private room for other reasons.
  • Consider the diversity of your speakers, particularly your keynote speakers, and the message that sends to (potential) conference attendees. If all your keynotes are being given (or appear to be being given) by the dominant demographic in your community, that can make your conference and community look like it excludes others, however welcoming it is in practice.
  • Before you introduce a speaker, make sure to ask what name they prefer, how to pronounce it, and what pronouns they use – even if it seems obvious. It‘s jarring for the speaker if you get this wrong just before they go on stage.

Ticket sales

  • If you have a limited amount of tickets and expect to sell out quickly, limit the number of tickets per purchase. That’ll give everyone a fair chance, and help get a mixed group of attendees, instead of a small number of companies buying out all the tickets.
  • When deciding when to open ticket sales, consider different time zones. 11:00 in Europe means Americans would have to wake up in the night to get tickets. 15:00 UTC often works fairly well for Europe and America, but not as good for Asia. You can sell in multiple batches at different times of day to give people from either region a chance.
  • If you think you might sell out, set up a waiting list. You could send any cancelled tickets here, and refund the person that needed to cancel. At Django Under the Hood, we re-sold three tickets the day before the conference, making six people happy.
  • If your tickets tend to sell out very fast, use a lottery instead. People can enter during an entire week, and you randomly select winners that then have one week to register and pay for their ticket. Any remaining tickets go back into the lottery. This promotes inclusivity and diversity, because if people only have a few specific minutes or hours to get their ticket, it’s easy for people with desk jobs, but might be impossible for those with other kinds of work or other responsibilities (e.g. parents).
  • Don’t sell all your tickets right away. Keep a small batch (5 or so) for unforeseen situations. You can always decide to sell them as last-minute tickets later.
  • If you have any side events, like a sprint, ask people in the ticket whether they will attend. That’ll get you some attendance numbers early on. Make sure people who are not familiar with sprints or another event can easily find what they are about.
  • Giving out t-shirts or other clothes? Ask people for their size when registering, and use this list at the registration desk when handing out the shirts. It speeds things up and helps make your t-shirt order more accurate.
  • Under absolutely no circumstances use PayPal for receiving payments. In general, be careful with who you give control over your funds. Get it to your own bank account as soon as possible.
  • Consider using a specialised ticket sales service. Organisers in the Python and Django community have had good experiences with EventBrite, DoAttend, Paydro and Tito. You can ask whether they'd be willing to sponsor by waiving some of their fees.
  • Consider having staggered ticket pricing. Give a discount for early bird sales and charge a premium the closer the tickets are bought to the event dates. This can result in more sales early on, giving you a better picture of attendance.
  • Consider having a limited number of tickets available at the spot, possibly at a significant premium. This incentivises normal ticket sales, but still allows for people who couldn't plan ahead dues to other life events.

Team

  • Do not run a conference entirely on your own. It’s a lot of work, and you need to have other people around that can relieve you of some tasks if it’s really needed, and help to find the inspiration you'll need.
  • Make sure to have some silent way of communicating across the entire team, that offers push messages too. A Slack, for example. There will be unforeseen issues, and being able to communicate within the team is essential.
  • If you have volunteers outside of the main team that help you with registration, goodie bag sorting, or anything else, don’t forget to thank them for their work. Even a private word of appreciation can make a difference.

Recordings

  • If you are making recordings, make sure you have at least have a dedicated person for this, but ideally hire a professional.
  • If you’re hiring someone to make photos or videos, make sure you carefully review the contract regarding intellectual property: by default the laws in many countries leave all rights with the creator you hired, even though you pay them.
  • Make sure you notify attendees in advance that recordings are being made.
  • Not all attendees might be comfortable being recorded or photographed. DjangoCon Europe 2015 and others have offered two different colour lanyards, where a particular color indicates that attendee does not want to be photographed or recorded. When you ask people which colour they want at your registration desk, you’re also making everyone else aware of the significance of lanyard colours.
  • Ensure that you’ve obtained permission from all your speakers for recording them. Many conferences include this in the call for papers.
  • If you are uploading talk recordings to services like YouTube that allow comments on videos, ensure the comments are moderated or disabled. Otherwise, you risk harassing comments being made, at any time after the conference, when your team is also probably less available.

Other

  • If your community uses Twitter a lot, keep a stream of informing tweets going from your conference accounts. Just before lunch, tweet a reminder of where lunch is served and what people with special dietary needs should do. In the early morning, tweet when the first talk will start that day. If you change locations, tweet a reminder in the evening and the morning with instructions on how to get to the new location. During the afternoon, a reminder about the party that night. It’s hard to stay on top of this during the conference, so at DUTH 2015 I scheduled about 30 tweets in advance in TweetDeck. Just remember to update them if your schedule changes.
  • If you are making badges, make sure the names are very visible. About half the conferences I visit print the names no larger than 14pt or so, which makes them impossible to read from any distance. Ideally, print them double sided as they tend to flip around.
  • Consider also asking for people’s pronouns during registration, and printing those on your name badges. This can make your conference much more welcoming to trans people in particular. Providing this information should be optional, and the options should include at least "He/Him/His", "She/Her/Hers", "They/Them/Theirs" and "Other (please state...)".
  • Always make a few extra blank badges, so that you can make some on the spot if needed, for example because you misprinted a badge.
  • Don’t forget to have fun :)

lessobviouschecklist's People

Contributors

mxsasha avatar alexwlchan avatar me-and avatar aeschright avatar skade avatar vsmart avatar glasnt avatar williln avatar shabda avatar

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.