I submitted a pull request to the Django project to fix an awkward example in the project’s developer documentation. Originally, a little piece of the coding style document presented an example of a model (simply put, an object representing some data) that provided a set of choices, a list of accepted values for some data in the model. The list of accepted values were male and female only. The portion of the document was meant only to demonstrate how a set of choices was to appear in the source code, not how to collect gender data. I proposed a small change (that was accepted) to render the example genderless, with a set of choices up and down (for, say, storing elevator usage statistics or something).
I wrote the revised example on the basis of one of the earliest lessons I had in technical writing. My first technical writing class in college was a service learning course. The course was something of an eye-opener, showing me challenges that are often invisible to a wealthy, healthy, able-bodied, hetero white guy. My classmates and I made a basic website for a Ryan White CARE Act consortium. The Ryan White CARE Act provides funding to help pay for care for people living with HIV/AIDS. Some of the funding is supposed to be spent with the recommendation of local consortia, made up of people in communities where the money is spent, including people who have HIV infection. At the start of the project, we did some introductory audience analysis, and surveyed members of the consortium about their needs and expectations.
Our first draft of the survey for the members included some seemingly innocuous demographic questions about the respondents’ city, age, and, yes, gender. Like the Django example, we supplied two choices: male and female. Luckily, before we distributed the survey to the consortium’s members, we learned how clumsy and insensitive our question was. Asking about someone’s gender is more challenging than you might guess. It presented two problems: the first being the accuracy of choices available to respondents, and the second being the message to respondents who aren’t represented by the available choices.
The first problem was that respondents who wanted to answer a question about their gender might have found that their preferred choice was not an option. So, for instance, a respondent might have preferred to choose non-binary, but the option was not presented. The respondent would have been forced to choose to answer less accurately than desired, or leave the question unanswered. Moreover, what constituted an accurate response might have also been unclear, as many people are stuck with a discrepancy between their gender identity and their legal identification (e.g., on a driver’s license or birth certificate). In our draft survey, all questions were optional, but the problem would’ve been exacerbated if we required responses.
The second problem is more troubling. By not presenting a broad range of choices, we ran the risk of alienating would-be respondents. Given the stigmatization associated with HIV, respondents would’ve been rightly suspicious of a survey that did not afford them the opportunity to represent themselves. By offering only male and female as choices, it needlessly implied exclusion to those who don’t identify with those options. Choices like that draw undue and unfair attention to some respondents’ gender identity more than others.
In the end, my classmates and I were faced with a choice of our own: make the question open-ended or eliminate it. We came to the conclusion that the gender breakdown of our audience didn’t matter much to our writing process, so we chose to drop it. When I came across that example in the Django documentation, I made a similar consideration. Since the point of the example code was to show a limited set of choices, it wouldn’t be possible to create an inclusive version, so I removed the need for it. Of course, credit to Adrian Holvalty of the Django project who accepted the pull request almost entirely without comment.
It’s not a costly edit. There’s no loss of clarity and it’s just a few bytes difference. But if you’re asking for help, whether it’s to code with a certain style for your framework or to answer a few questions for a website, it pays to include—or at least not exclude—the people you’re asking. Small incremental changes like these are an important step in reaching the fullest extent of your audience.