# \[RFC\] GenderInference.jl

**URL:** <https://discourse.julialang.org/t/rfc-genderinference-jl/22294>\
**Category:** Data\
**Tags:** diversity\
**Created:** [March 25, 2019, 9:49am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294 "2019-03-25T09:49:47Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 27, 2019, 9:17am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/21 "2019-03-27T09:17:57Z")

</div>

> [@dellison](#):
>
> Either way, it might also be [a good idea](http://white.ucc.asn.au/DataDeps.jl/stable/z20-for-pkg-devs.html#Registering-a-DataDep-1) to have the `register(DataDep(...))` happen inside an ` __init__ ()`

At one point I tried this and had problems with it. Don’t remember why, and I didn’t try _that_ hard to fix it, but I can revisit. Thanks for the ideas!

> [@dellison](#):
>
> it seems to me that providing code to “infer” a binary gender from surface features (i.e., a person’s name) could be seen as assuming some specific political ideas about gender, even if you don’t mean it that way.

A totally valid concern, and this goes beyond the package name. On the other hand, of a trans person selects a name that reflects their gender identity, presumably this tool would pick that up. Not sure how to deal with the binary nature though - do you have any suggestions?

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 27, 2019, 9:29am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/22 "2019-03-27T09:29:16Z")

</div>

> [@bennedich](#):
>
> How about exposing the raw data through your package?

Not exposed at the moment, you’re correct. You can do `GenderInference.NAMES` to get the dictionary for now. I agree it would be good to expose it more directly. I think based on earlier discussion I’m going to split out data curation from data queries, which might make this a bit more straightforward.

> [@bennedich](#):
>
> For faster support of range queries, the data structure I’d choose for this is not a dictionary of year -\> count, but a cumulative array of counts

Interesting - the only downside being killing track of which years have data as the data set expands. And keeping track of two different vectors (or I guess I could have a vector if tuples).

> [@bennedich](#):
>
> Also, if space is an issue, consider not using 64 bit ints for the counts. 32 bits should probably suffice.

Solid idea. Should be easy 🙂

> [@bennedich](#):
>
> in the opinion of a non-American, this plays on the stereotype that Americans are unaware that there are other countries out there than the US

What? Where? 😆

I guess the ambition is to support more countries, do you think it would be sufficient to be more explicit that it’s only a US dataset for now?

> [@bennedich](#):
>
> Since you are using the names of other prolific Julia contributors, I’m wondering if this should be “Kristoffer”? 🙂

😬 Thanks for pointing that out … Will fix.

---

<div class="post-metadata">

**Author:** ![bennedich](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bennedich/32/4894_2.png) [@bennedich](https://discourse.julialang.org/u/bennedich)\
**Post date:** [March 27, 2019, 11:04am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/23 "2019-03-27T11:04:08Z")

</div>

> [@kevbonham](#):
>
> Interesting - the only downside being killing track of which years have data as the data set expands. And keeping track of two different vectors (or I guess I could have a vector if tuples).

I would hold off with the two different vectors until you determine that it’s really necessary. Subtracting two numbers adjacent in memory should be cheap enough for most applications, and I suspect that a low memory footprint would be preferred over saving a nanosecond per lookup. There are also cache benefits to having a single, more compact, vector, so it might not even be slower in practice.

As for the total size of the dataset – I’m seeing 97,310 unique names, so with one count per 140 years that’s 13,623,400 counts, which for 32 bit counts corresponds to ~52 MiB of data. That doesn’t sound terrible to me, but if you add support for more countries for example, it might add up.

One way to reduce the memory footprint would be to use a variable number of bits per name to store the counts. So, for the name William for example, you might need 22 bits to represent the maximum count, while for a name like Xzaviar, 7 bits may be enough. And then pack the counts as tightly as possible (bit by bit). I’m guessing that the majority of names are quite rare, so this would save a ton of space.

You could also save only the range where each name has any data. So if the first year that Xzaviar appears is 2001, and the last is 2017, there’s no need to store a bunch of zeros for years 1880 - 2000. You could store the first year (2001), the count of years (17), the bit size (7), and then 17 \* 7 bits of counts.

> [@kevbonham](#):
>
> I guess the ambition is to support more countries, do you think it would be sufficient to be more explicit that it’s only a US dataset for now?

Sounds like a good plan 🙂

---

<div class="post-metadata">

**Author:** ![dellison](https://avatars.discourse-cdn.com/v4/letter/d/ce73a5/32.png) [@dellison](https://discourse.julialang.org/u/dellison)\
**Post date:** [March 27, 2019, 11:41am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/24 "2019-03-27T11:41:40Z")

</div>

> [@kevbonham](#):
>
> On the other hand, of a trans person selects a name that reflects their gender identity, presumably this tool would pick that up. Not sure how to deal with the binary nature though - do you have any suggestions?

Well, I think it’s sensible just to provide a model over the census data as it is, that’s the packages purpose. I didn’t look at that part of the code too closely but it looks like that’s what you’re doing already. 🙂 If the model is specific to the US census data, maybe it makes sense to have name the package in a way that makes that obvious.

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 27, 2019, 12:12pm UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/25 "2019-03-27T12:12:16Z")

</div>

> [@DNF](#):
>
> Shouldn’t `percentmale` be 100.0 here? Alternatively, the name could be `fractionmale` .

Yeah, I thought about that. Really don’t like `fraction` though. Makes me think of eg `3/4`. I thought about `pfemale` or `propfemale` for “proportion”, but not really a fan…

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 27, 2019, 12:14pm UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/26 "2019-03-27T12:14:12Z")

</div>

> [@dellison](#):
>
> If the model is specific to the US census data

That’s the way it is now (it’s social security rather than census), but the goal is to expand beyond that. Maybe `BirthNameGenders.jl`?

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [March 27, 2019, 2:23pm UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/27 "2019-03-27T14:23:10Z")

</div>

But in that case it should return 100.0 instead of 1.0, wouldn’t you say? If I get `percentsomething()` returning 1.0, I will for sure think it’s 1%.

---

<div class="post-metadata">

**Author:** ![dellison](https://avatars.discourse-cdn.com/v4/letter/d/ce73a5/32.png) [@dellison](https://discourse.julialang.org/u/dellison)\
**Post date:** [March 27, 2019, 7:04pm UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/28 "2019-03-27T19:04:11Z")

</div>

Ah, right- social security data, not census. Thanks for the correction!

Or perhaps `NameGenderDemographics.jl`, or something sort of like that? I dunno, it’s hard to come up with something that’s both generic and obvious. In any case, I’m glad that you see my point and are giving it some thought. 🙂

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 27, 2019, 8:33pm UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/29 "2019-03-27T20:33:34Z")

</div>

> [@dellison](#):
>
> I’m glad that you see my point and are giving it some thought. 🙂

For sure! Probably the best thing to do is ask some gender queer people rather than trying to speculate about what they would find objectionable. I only know one trans person (to my knowledge). Maybe Twitter?

---

<div class="post-metadata">

**Author:** ![dellison](https://avatars.discourse-cdn.com/v4/letter/d/ce73a5/32.png) [@dellison](https://discourse.julialang.org/u/dellison)\
**Post date:** [March 27, 2019, 10:35pm UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/30 "2019-03-27T22:35:57Z")

</div>

So after a little more thought, I’ve sort of found myself having settled on an stronger position than I had at first: basically, I think that it is categorically impossible for an ethically sound model like this to exist at all.

Here’s a brief article on this specific use case from an HCI researcher who I admire: [Stop Mapping Names to Gender](https://ironholds.org/names-gender/) I find their arguments very convincing, so I think at this point I would urge those in the thread to to consider this carefully, and excuse myself from the discussion.

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 28, 2019, 12:06am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/31 "2019-03-28T00:06:01Z")

</div>

> [@dellison](#):
>
> Here’s a brief article on this specific use case from an HCI researcher who I admire: [https://ironholds.org/names-gender/](https://ironholds.org/names-gender/) I find their arguments very convincing,

Thanks for sharing! Definitely a useful perspective to keep in mind, though I don’t entirely agree.

---

<div class="post-metadata">

**Author:** ![dellison](https://avatars.discourse-cdn.com/v4/letter/d/ce73a5/32.png) [@dellison](https://discourse.julialang.org/u/dellison)\
**Post date:** [March 28, 2019, 2:00am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/32 "2019-03-28T02:00:48Z")

</div>

One last thought:

> [@kevbonham](#):
>
> Probably the best thing to do is ask some gender queer people rather than trying to speculate about what they would find objectionable. I only know one trans person (to my knowledge).

> [@kevbonham](#):
>
> Definitely a useful perspective to keep in mind, though I don’t entirely agree.

From my point of view, it seems like that when you _did_ get the opinion of a person like you described, and who additionally is actually a researcher whose area of expertise is precisely what we are discussing, you quickly dismissed them and decided that you know better.

(edited, since I think I was a little combative originally… sorry about that)

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [March 28, 2019, 6:07am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/34 "2019-03-28T06:07:38Z")

</div>

Is there no room between fully agreeing and quickly dismissing?

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 28, 2019, 1:54pm UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/35 "2019-03-28T13:54:22Z")

</div>

> [@dellison](#):
>
> One last thought:

Doesn’t need to be. I’d be happy to discuss over DM or email or another forum if you’d rather not continue the conversation here.

> [@dellison](#):
>
> From my point of view, it seems like that when you _did_ get the opinion of a person like you described, and who additionally is actually a researcher whose area of expertise is precisely what we are discussing, you quickly dismissed them and decided that you know better.

Not a quick dismissal, I take this perspective seriously. Also don’t think I know better, I’m just not entirely convinced that this is everywhere and always a bad idea, and would like to hear more perspectives. I’ve reached out to my trans friend (who also works with a lot of trans people).

Also, recall that we were discussing the name of the package, not whether the method itself was ethical.

I **am** pretty convinced that this is not a good way to measure diversity at a conference or in a company, which is that author’s main thrust it seems. I’m interested in using it to measure gender representation in publications ([See here](https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005134) for an example), where it is not feasible to survey or otherwise determine the gender of hundreds of thousands of authors, so the work just wouldn’t be done without this or similar methods. We are also up front about many of the limitations of this method that are mentioned in the blog post.

I do think I will include a link to that post in the README, so users are at least made aware of that perspective.

> [@dellison](#):
>
> edited, since I think I was a little combative originally… sorry about that

It’s a fraught subject. Makes sense that one or both of us would get combative. No hard feelings 🙂

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 28, 2019, 2:19pm UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/36 "2019-03-28T14:19:56Z")

</div>

> [@dellison](#):
>
> (Either way, it might also be [a good idea](http://white.ucc.asn.au/DataDeps.jl/stable/z20-for-pkg-devs.html#Registering-a-DataDep-1) to have the `register(DataDep(...))` happen inside an ` __init__ ()` ).

Alright - I’m back to this. When I put `register()` inside ` __init__ `, ([see here](https://github.com/kescobo/GenderInference.jl/blob/discourse/src/GenderInference.jl#L15-L21) - init currently commented out), I get

```julia
ERROR: LoadError: LoadError: LoadError: KeyError: key "US Census - names" not found

```

And apparently I can’t do a `global const` declaration inside the ` __init__ ` function.

I’ve removed precompilation on that branch though - any chance you could test to see if the same infinite loop occurs?

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 30, 2019, 9:46am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/37 "2019-03-30T09:46:19Z")

</div>

> [@bennedich](#):
>
> For faster support of range queries, the data structure I’d choose for this is not a dictionary of year -\> count, but a cumulative array of counts.

Can I clarify something? I should still user a dictionary for the names to access these arrays right?

---

<div class="post-metadata">

**Author:** ![bennedich](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bennedich/32/4894_2.png) [@bennedich](https://discourse.julialang.org/u/bennedich)\
**Post date:** [March 30, 2019, 10:31am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/38 "2019-03-30T10:31:41Z")

</div>

Yes, I think that makes most sense, to allow for constant time lookups by name.

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [July 21, 2020, 3:15pm UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/39 "2020-07-21T15:15:18Z")

</div>

I’m reviving this thread based on comments [from here](https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005134). This revival will be focused on the ethics of the approach rather than the technical aspects. For those uninterested in this aspect of the discussion, please feel free to unwatch/unsubscribe (and also feel free to DM me if you don’t know how to do that).

> [@Ethics in Julia](https://discourse.julialang.org/t/ethics-in-julia/43232/72):
>
> but are you referring to this piece? [https://ironholds.org/names-gender/](https://ironholds.org/names-gender/) If so, you and I must have read it quite differently- in my reading, the author’s argument is not that it’s unethical to do merely in an in-person or similar setting when you can simply ask for this information in a different way, but that (my paraphrase) predicting gender from given names is unethical to begin with, because setting up the task that way in the first place implicitly bakes in very specific political ideas about gender that themselves are unavoidably racist and so on. That’s not application-specific, to my mind.

I don’t think it comes down to different readings. Rather, I think the author is responding to situations (like conferences) where a survey would be just as easy, yield better/more accurate data, and not have all of the problems this approach has. I agree that the author would likely extend the argument to other use-cases, but doesn’t really address them, and as a consequence, I find it less persuasive.

For example, two of the three primary objections don’t really seem to apply for the use-case I’m primarily interested in, or at least the case wasn’t made. Reason (1) that it’s “inaccurate” isn’t applicable because (a) no measument in science is perfect, and one can assess and account for error (b) the author erroneously talks about the databases as coming only from the top 100 names, but most that I’ve seen come from things like socal security records than include all names (I think as long as they show up at least 2 times in a given year) (c) I can show how it compares (favorably) to other more laborious methods such as manually looking at social media profiles and looking at self-stated gender (d) the biases w/r/t things like Asian names being under represented or impossible to infer from especially after romanization, are real and should be acknowledged, but even if we expect gender trends in science publishing to be radically different between those that are represented in the database and those that aren’t, pointing out disparities only in the communities that _are_ represented still seems worthwhile.

The third objection that it’s usually unnecessary only addresses the conference situation, and no solution for my use case is offered. Yes, surveys of academics are possible, but far more costly and time consuming, and suffer from their own problems of bias. I’m any case, I would be unable to do this due to time and budget constraints. So one could argue that the work isn’t worth doing, given the other objections. Or one could argue that there’s a better way to do it, given time and budget constraints, but these arguments weren’t made.

The final objection, that it’s morally horrifying, I just find unconvincing. Quoting from the piece here:

> The voids in these datasets don’t cover everyone evenly. Rather, they often fall straight down lines of race, culture and ethnicity.

Totally agree.

> Accordingly, names that are largely unique to non-white groups are far more likely to be excluded from a top-N dataset than common names used by white people, for the simple reason that there are _fewer non-white people_ .

This has a glimmer of truth but not for the reasons started. As I said above, most of the software I’ve seen (and this package) use datasets that are far more inclusive. There are lots of non-white babies born in the US, and so lots of non-white makes included in the datasets. Add to that, there are plenty of non-white babies named David or Sara.

That said, there are clearly biases. I’ve already mentioned a general problem of Asian names, especially when given romanized spelling, but there’s also the problem of non-ASCII characters being excluded or paved over in a way that obscures/changes the implied gender, plus the fact that the entire continents if Africa and South America tend not to publish such data sets.

All stipulated.

> Congratulations: your methodology is racially biased.

So, this is true, but that’s different than saying it’s racist.

> The result is, invariably, that you end up with a model that underrepresents people of colour, be they from European/North American contexts or elsewhere. Both are _vital, non-excludable_ populations to consider in even the most half-hearted inclusion initiative.

I agree with all of this, but all models are wrong. Some are useful. This author seems to be arguing that, unless you can get a census-like count, there’s no value in assessing the gender make up of anything, ever. From earlier in the post:

> there’s considerable variation in the data: ambiguous names that you can at best _probabilistically_ tie to a binary gender. “Sam” could be of any gender or none.

Again, stipulated. This point is written as if it’s some kind of scandal. In some situations, a probabilistic model can provide valuable, if imperfect insight. At least, I think so. I’m open to being persuaded.

The issue of erasure of trans/non-binary people is the part I’m most conflicted about, though I find this person’s arguments really unconvincing, eg

> Frankly, claiming that birth name maps immutably to gender in the first place is the kind of essentialist TERFy nonsense that has no place in inclusion efforts.

This feels like fighting a straw man - I would certainly never claim such a thing. I won’t go through them all, but many other points strike me to way - as if my algorithm would say that Sam is 80% likely to be male, so whenever I met someone named Sam I’ll treat them like a stereotype of a man and refuse any other information.

There’s no argument that addresses what to do if I have a dataset of 100 Sams, 100 Sallys, 100 Roberts and 100 Yishans. Should I say that, because the Sams and the Yishans are ambiguous, and that some of the Roberts and Sallys might be trans or non-binary people that I have absolutely no information?

But even getting past all of that, it could be possible that simply trying to study the inclusion of women, without addressing trans people, is too exclusionary. Does this mean that we can’t talk about the gender pay gap without taking about figuring out whether there’s a trans pay gap? Can we talk about how women take on more childcare responsibilities in general, and how this is being exacerbated by COVID with children being out of school, if we can’t also assess the impacts of childcare responsibilities on non-binary people?

I 100% believe that trans and non-binary people have very different experiences, are generally more marginalized, and deserve to be acknowledged and taken seriously. And the same for POC. If I were on a committee that oversees grant proposals, I would absolutely look to fund efforts trying to assess their contributions in science publishing, which could obviously not be done with this method. But none of that send to indicate that trying to address the role of women (even if it mostly only applies to cis women) is bad.

> [@Ethics in Julia](https://discourse.julialang.org/t/ethics-in-julia/43232/75):
>
> If you don’t mind me saying so, perhaps you can try to imagine why reading a remark like this from you might make me inclined to think that it might not be a totally fruitful discussion. If you recall, I shared that post in direct response to you saying that you wanted to know the opinions of nonbinary people on the subject. I pointed out that not only is the author of this piece nonbinary themselves, but is a researcher whose specific area of academic expertise is gender issues in technology. Seeing you now characterizing that expertise and experience as “the opinion of Random Person on Internet” isn’t very encouraging to me.

I don’t mind at all 🙂. You’re right - this was not the best way to refer to this person. In the heat of the moment, I was responding to someone that I felt was accusing me if the equivalent of “I have a friend who’s black, so I can’t be racist.” I don’t think that having a non-binary friend means that I can’t have bias, but I sought out that person’s opinion because they are non-binary _and also_ spend their life and career in trans-activism. My response was intemperate, to be sure, but I don’t think the author of that piece necessarily had more credibility than my friend.

> [@Ethics in Julia](https://discourse.julialang.org/t/ethics-in-julia/43232/72):
>
> Looking that thread again, it looks like that package was intended for making binary gender predictions for authors of academic work, so here’s a recent (short) paper on that specific use-case, if you (or anyone else) would like to take a look. [https://www.frontiersin.org/articles/10.3389/fdata.2019.00029/full](https://www.frontiersin.org/articles/10.3389/fdata.2019.00029/full)

This is an excellent paper! I think I will need to re-read a couple of times (currently in vacation, so didn’t do a deep dive), but I think that there’s a lot of stuff that’s relevant to my research and to this package.

I will note though that these authors took a similar approach for one of their papers, and are not arguing against the practice categorically. They offer a number of suggestions to make such research more aware of and cognizant of these biases to be sure - and I think this is super valuable.

---

<div class="post-metadata">

**Author:** ![dellison](https://avatars.discourse-cdn.com/v4/letter/d/ce73a5/32.png) [@dellison](https://discourse.julialang.org/u/dellison)\
**Post date:** [July 22, 2020, 3:17am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/40 "2020-07-22T03:17:32Z")

</div>

> > Congratulations: your methodology is racially biased.

> So, this is true, but that’s different than saying it’s racist…

A distinction without a difference. I guess all I can say at this point is that while I hope these exchanges have been valuable, I also hope that they haven’t inadvertently contributed to a little bit of precedent for the Julia forums being a place where the upsides of self-consciously trans-exclusionary and racially biased research methodologies can be discussed openly.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 22, 2020, 8:04am UTC](https://discourse.julialang.org/t/rfc-genderinference-jl/22294/41 "2020-07-22T08:04:45Z")

</div>

> [@dellison](#):
>
> precedent for the Julia forums being a place where the upsides of self-consciously trans-exclusionary and racially biased research methodologies can be discussed openly

I hope that the Julia forums will remain a place where _all_ kinds of research methodologies can be discussed openly, even if they are imperfect from a particular point of view.

Working with data always involves trade-offs and assumptions, some of which are prone to biases. Sometimes it is difficult to do any better though (until someone comes up with a better methodology, or data), in which case it is important to be aware of these biases.

Stifling discussion about them would have the opposite effect.

[Previous page](https://discourse.julialang.org/t/rfc-genderinference-jl/22294.md?page=1)

[Next page](https://discourse.julialang.org/t/rfc-genderinference-jl/22294.md?page=3)