Let's make this more than binary #3

lsblakk opened this Issue Oct 21, 2013 · 11 comments


None yet

9 participants


I'd like this amazing idea to benefit from more than just women:men identities - let's broaden and allow for people to self-id in other categories then analyze the data accordingly.

eg: instead of pulling num_female_eng and num_eng let's say grab num* and chart that so a company could have (and people could make pull requests for data that looks like):

company: Name
num_women_eng: 13
num_men_eng: 92
num_transwoman_eng: 2
num_genderqueer_eng: 1
last_updated: 10/20/2013

Then sort this based on whatever is between num_ and _eng to get the columns or whatever.

I could submit a patch for this probably but putting it in an issue in case anyone else wants to tackle this before I get to it. Thanks for doing this!


In that case it really should be num_cis_women_eng and num_trans_women_eng -- because otherwise, a trans woman would be double-counted as both "women" and "trans_women".


I like the spirit of this but I am worried that it turns the scope from "this is an easy number to obtain" (employee genders that every company reasonably records) to "aggregates on personal properties that are hard to measure consistently and possibly illegal for a company to record".


I'm not sure it changes the scope -- at least in the US, employers don't normally keep track of employees' genders (except for affirmative action statistics that are normally confidential; at one point it was necessary for Social Security, but it isn't anymore). So if I were to collect these statistics for my company, I would be guessing genders based on names; or, for people I knew personally, using the gender I know they are, whether that's genderqueer, male, female, genderfree, etc.

@WheresAlice WheresAlice added a commit to WheresAlice/women-in-software-eng that referenced this issue Oct 23, 2013
@WheresAlice WheresAlice Add extra gender fields
Add a field for male engineers and suggest other gender fields are acceptable.

Resolves #3

Instead of an itemized list of identities, perhaps it would be better to simply have
Number of female, number of male, number of non-binary identified engineers.
Though I respect the arguments that this data is harder to collect, especially for the larger companies


I would be ok with three fields to keep it simple. I mean ideally, you'd want to be able to accept any data on non-binary genders that is available, but pragmatically three fields keeps it simple.

My only minor concern is that there is a difference between a company saying zero non-binary employees and not using the field at all. By saying zero, just because they don't have that data, is contributing to non-binary invisibility.


One caveat, especially since many tech companies are small, is outing people. If people want to self report non-binary or trans IDs, that's different than a coworker including that information here because they happen to be privy to it. At many companies, it would be easy to extrapolate from such small numbers someone's identity.


The same argument can be made against keeping binary options, if somebody submitting data is choosing a binary gender for somebody who is non-binary then there's a good chance of them getting it wrong.


Could introduce a small change of modifying the data by +1/-1 here to add plausible deniability. Makes the data less accurate, but protects people who might not be out. Might spark some interesting discussions. :)


as a trans person i think delineating transness is actually kind of othering of trans people in this case? trans women are women.

however i do strongly desire at least a third category for all nonbinary genders. women/nonbinary/male is easy enough, isn't it? it bothers me that the data visualisation for /this data assumes binary genders are the only ones that exist.


👍 for non-binary data (while not separating trans stats out).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment