Improving diversity and inclusion at tech (and other) events

Over the years I’ve attended and organised various conferences, hackathons, and other events, and it’s been interesting to observe the ways in which each of them handle (or don’t handle) diversity.

This post is a collection of notes and pointers about the things I’ve noticed are some of the most important things to help increase diversity at events. When I say diversity, I’m largely referring to the diversity of the attendees at events. People from different walks of life, backgrounds, races, genders, abilities, etc.

Being inclusive at our events is important. If our events only have homogeneous attendees, the things they focus on will only be relevant to those attendees, and not useful to anybody else. As it turns out, not everybody is a neurotypical able-bodied heterosexual middle-class cisgender white male. Those of us who do fit or approximate this description often aren’t aware or appreciative of the issues experienced by anybody different from ourselves.

So, in no particular order, how do we improve diversity? This is by no means an exhaustive list, and there will be things I’ve missed, and perhaps some mistakes. Please check out the references section for more information. There’s also a summary at the end. (EDIT: The summary is also available as a lightning talk.)


Be sensitive to and aware of non-white attendees. Ensure you call out racism in your code of conduct, and that you consider how you can be inclusive of and do outreach to various races and indigenous communities.


Have accessible venues. This means ensuring that all the important areas of your venue, including common areas, theatres, bathrooms and stages (speakers can have disabilities, too, and may have lots to say about them!) are wheelchair accessible.

If you think you may have people with visual or hearing disabilities at your events, consider a sign-language interpreter, or having a hearing-aid loop, so that these people can be involved in presentations too, and encourage presenters to be cognisant of this when making their slides (not assuming everybody can see what their slides say, for example).

Additionally, speakers should be mindful of using ableist language, or abusing terms like “OCD” to mean “fussy,” for example. Ensure your website is accessible for people with screen readers etc.

Dietary requirements

Ask for people’s dietary requirements upon registration for your event. You could have a set of check-boxes for things like vegetarian, vegan, gluten free, lactose free, FODMAP, etc. but regardless of whether or not you do this, you should include a dietary requirements free text field for people to explain the nuances of their situation; don’t assume they’ll fit into your boxes; people are complex.


There are more than 2 genders, and we want to be inclusive of them all. That means that beyond making our events more accessible to women, we should also be inclusive of trans, non-binary, and gender-non-conforming folks. This should include, wherever possible, gender neutral bathrooms.

If your event will have name badges, and you want to give attendees input into what goes onto their name badge, then instead of permitting a “Twitter handle” text box, have a “free badge text; use for Twitter handle, pronoun, GitHub profile, or whatever you like” field. The mention of pronoun here demonstrates to attendees that you acknowledge people’s pronouns may not match how they look (a femme presenting person may not use she/her/hers pronouns), and improves inclusion.

If you need to ask for gender ensure you allow a free-text field to specify their gender. Again, they may not fit in your boxes. Ask, though, why you are asking for gender? Identifying diversity (e.g. how many non-men do we have at this event) is a valid reason. An argument people have made in the past is that a free text field could result in: man, male, boy, masculine, guy, woman, girl, lady, female, trans man, trans woman, unspecified, etc. This is obviously a bit tricky to aggregate for statistics, so one option is to offer an auto-complete text field that auto-completes to “female” when the user starts typing “f” or other words, for example. This encourages users towards labels that make statistical aggregation easy for you, but lets them break out of your boxes if they wish, and type what they like.

Additionally, “unisex T-shirts” are not unisex. Unisex shirts are not designed properly to fit people with breasts or differently shaped chests. If you’re offering T-shirts, offer women’s cut shirts as well as unisex/men’s cut shirts. This may also mean thinking carefully about the design you print on your shirts to ensure the design looks good on people with larger chests, and that the design isn’t distorted etc. Consider subtle and unintentional use of gendered language, such as words like “guys.”


Not everybody has a first name and a last name. Some have mononyms, other cultures display the family name first. When asking for people’s names on your registration form, have a single field for somebody’s full name. Don’t split it up. Ever. If you want a short or informal name (what we westerners may usually use a first name for), have an additional field for “informal form of address”, and explain this may be used for address in newsletters etc., so people have a context through which they can decide how to be addressed.


Not everybody will be able to afford to come to your event. People from low socio-economic backgrounds may want to come, and have useful and interesting input and perspectives. We can’t afford to exclude these people. Offer grants or sponsorships to people who can’t afford to attend but wish to.

Childcare and youth programs

Some potential attendees will have children. Offer childcare or youth programs. Childcare is not hard to do, and demonstrates your desire to make your events family-friendly.


Going to a new event can be scary. Include details on your event’s website that are easy to find and explain what to expect for your event, possibly offering a contact of whom additional questions can be asked. Once at your event, ensure that newbies are overtly welcomed, and that contempt culture is discouraged.

Code of Conduct

Have a code of conduct. There are plenty of great CoCs available (some of which I’ve mentioned in below in the references) off which you could base yours. It should include consequences for breaches, and details for who to contact if people feel unsafe or need to report an incident.


Additional references and further reading

See Carina C. Zona’s talk called “Schemas for the real world” for information on how to ask for information from users without squeezing them into boxes into which they don’t feel they fit. Check out the Django Community Code of Conduct, the Hopper Fund’s guide to improving conference diversity, the Geek Feminism anti-harassment policy, and the anti-harassment policy developed by the Ada Initiative.

Regarding inclusive language, the Australian National LGBTI Health Alliance has an excellent guide to inclusive sex and gender diverse language. Feel free to extrapolate the guidelines for size, ability, education and ethnicity. The Australian Network on Disabilities also has a guide to inclusive language you might want to look at.


Upgrading from Mac OSX 10.6 to 10.7


Over the weekend I decided to upgrade my MacBook from MacOS 10.6 Snow Leapord to MacOS 10.7 Lion, for no particular reason other than “it seemed like a good idea at the time”. I encountered a few minor issues in the process, but it was mostly painless except that my Time Machine backups stopped working. This post details some of the issues I encountered and how I solved them.

Performing the upgrade

Upgrading to MacOS 10.7 has been made quite easy. If you’re running Snow Leopard, you simply purchase Lion in the App store, and download the installer. Once the 3+ GB installer is downloaded and has begun, you can optionally burn the image to a DVD or write it to a bootable USB key.

Your next step is to actually perform the upgrade, which should be as simple as following the prompts for the installer. This will cause a reboot or two, after which the installation should be complete.

Fix anything that Lion changed against your will

Lion has some different defaults to Snow Leopard, at least 2 of which I didn’t like. These two were:

  • Inverted scrolling

    Apple, in their infinite wisdom, decided that the scrolling direction when using a trackpad was not good enough, and inverted it. This was a bit of a shock, so I went and inverted it. Depending on your setup, you may need this link, or the first point in this one.

  • Remembering window and application state

    In Lion, unless you specifically tell them otherwise, many applications will remember which windows and files they had open after you quit them, so that it can resume them later when you start it back up again. I didn’t like this behaviour, so I turned it off. The recommendation is apparently that you *don’t* do this, but instead disable it for specific applications… or something.

Configure Time Machine (again)

For those of you that don’t know, you can use a Linux server as a Time Capsule for Time Machine and therefore store your backups there. This required a bit of configuration for Snow Leopard, but for Lion, there were extra changes that needed to take place for it to work again.

Lion uses a newer version of the Apple File Protocol (AFP), version 2.2, and this hasn’t been packaged for many Linux releases yet, as it’s either deemed unstable, or has been until recently.

I followed this guide for how to reconfigure my Debian Squeeze server to talk to Lion, but instead of downloading the packages listed on the site, I manually downloaded the source code for Debian Wheezy and compiled it on my server. There’s a bit of information in the above guide’s comments about caveats with this (such as needing to install libacl1-dev on the machine doing the compiling, despite it not being listed as a dependency).

The basic gist of how to get the sources compiled and installed on Debian Squeeze is:

mkdir netatalk
cd netatalk
dpkg-source -x netatalk_2.2.1-1.dsc
cd netatalk-2.2.1
# At this point you may be notified about unmet dependencies, such as:
#   dpkg-checkbuilddeps: Unmet build dependencies: libdb-dev
# Install these dependencies, whatever they may be:
sudo aptitude install libdb-dev
# Then try again
cd ..
sudo dpkg -i netatalk_2.2.1-1_i386.deb
# Again, at this point there may be complaints about dependencies not
# being met by this package. You should be able to resolve these by
# choosing one of the resolutions offered by:
sudo aptitude install

Now assuming you’re doing this from scratch, you should be able to basically take the config provided in the guide I linked to without too many requred changes.

I ran into issues because I was using a config file from the older release of AFP, and spend a long time trying to determine why it wasn’t working before realising that I needed the ‘tm’ option in the AppleVolumes.default file to denote that this share is usable by Time Machine. After adding this everything Just Worked.


So the process was more painful than I expected, and I suspect that if I’d known I’d have to jump through the above hoops to try and make the required changes in order to adapt (some of which I did until 3am Saturday night :S), I probably wouldn’t have bothered forking out the ~$30 it cost for the upgrade, given that so far I’ve seen very little benefit. Having tackled the problems I considered major now though, hopefully others can benefit from my experience.