This repo is an abbreviated version of the article I posted in June of 2018 on Medium—it might be helpful to go and read that first. The goal for the article and this repo is to create a hands-on, actionable, guide that anyone can use.
This guide is for people and companies planning and hosting events. The focus is on tech events, specifically, gender inclusivity at tech events, but it would be easy to adapt. Please note that this isn't a terminology guide per se, but instead a framework for thinking about diversity and participation.
Before you dive into the hands-on part of this guide, let's get on the same page with some basic premises:
-
Unconscious bias is real and affects everybody. As event planners, organizers, and participants, we may not notice something we do or neglecting to do. Some things carry a negative signal that prevents someone who has a different gender, sexuality, race, class, educational background, ability, religion, body size, or other identity marker from participating in an activity.
-
Ways in which we plan, market, and host events/activities may not feel inviting, safe, or even feasible to people from underrepresented minorities. We may not see the ways we aren't being inclusive due to unconscious bias. Attendees may not tell us that they don't feel safe. They may not even attend, and therefore we might think they don't exist.
-
Our events and groups are better when, in general, more people participate. They are made even better when people participate who are different from the majority of people represented in the group's current demographics.
-
In order to increase participation, especially that of underrepresented minorities (URMs), simply marketing our existing event to those groups/individuals is not enough. We must assess whether or not we are sending unconscious signals with our planning, marketing and running of events that prevents URMs from attending and/or feeling included. Then, we must follow these assessments with actions that ensure that URMs who attend will have a positive experience.
-
When people feel included, they participate, which benefits everyone.
- Different markdown files are for different aspects of the event process.
- I'd love to have more contributions to the resources!
Fork the repo, add some content, and submit a pull request.
If you do not (yet) know how to do the above, you might want to watch this video on how to fork a GitHub repo and submit a pull request.
This is a sensitive topic, as it deals with real issues real people face every day. It can be tough out there.
If something in this guide hits a sensitive spot, seems totally wrong, or doesn't mesh with your experience, I invite you to write down exactly what you are feeling in an email or on paper, and then wait 48 hours and see if that feeling lingers.
If it does, it's time to get in touch with me. Your concerns will be heard - I have space to hear where you stand. Open an issue or ping me on twitter.
Clearly reactionary or trollish behaviour won't be considered as neither I nor you (really) have time for that. Life is short and precious.
Thank you for contributing!! You are what the world is waiting for.
<3