Change default gender in the dining philosophers project

[sferik]

The paper from which this example was taken made the mistake of assuming that all five philosophers are men. This it is a hypothetical example—there are no actual philosophers eating 🍝—so there is no good reason to make this assumption. Since women make up about half of the human population, all things being equal, women should represent about half of the philosophers. However, because this mistake has stood since 1985, I have changed all of the pronouns to be female, to make up for lost time. If someone would like to revert this patch or switch to neutral pronouns after 30 years, feel free to set your alarm clock for 2045.

r? @steveklabnik, since this is a documentation change and was created after reading http://words.steveklabnik.com/ouroboros, where I noticed this mistake.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see CONTRIBUTING.md for more information.

[steveklabnik]

So, @sferik , I am super down with not using 'he' as a default, but this is a quote from the CSP paper. Changing it means it's no longer a quote.

Thoughts? I mean, I guess that this PR is basically saying "doing this is worth loss of accuracy", but changing a directly quoted source is something that gives me pause.

(Any other default gendered pronouns elsewhere should absolutely just be 'they')

[jdm]

Could we use [she] or [they] to indicate the modified nature of the quote?

[steveklabnik]

Yeah, something like that may be a good split.

Is there any precedent for this, linguistically? Or writing guidelines of some kind? I don't know.

[jdm]

http://writingcommons.org/open-text/research-methods-methodologies/integrate-evidence/incorporate-evidence/453-inserting-or-altering-words-in-a-direct-quotation
http://library.spokanefalls.edu/guides/quotingMLAstyle.stm

[aturon]

I'm personally happy to take the PR as is. I don't think the fact that it's a no longer an exact quote should get in the way, nor do I think we need to mark it as such.

If others feel it's really important to note the change, could we just have a parenthetical or footnote pointing out the change?

[steveklabnik]

@jdm oh duh, I do this ALL THE TIME on Twitter.

@sferik , what do you think about using [they]?

[sferik]

@jdm In my view, if steveklabnik@83df71d is merged without requiring that mistake to be corrected in the source material first, that sets a precedent for diverging from the source material to correct mistakes without making a note of the alteration of the quote.

Another option would be citing the paper by Tony Hoare without quoting it directly.

[sferik]

@steveklabnik I am against the use of [they] because I don’t believe that goes far enough to correct historical injustice, as I indicated in my commit message. If you want to make the change to [they] in 30 years, I wouldn’t object. I’m also starting to wonder why #25575 was not held to the same level of scrutiny.

[steveklabnik]

Fair enough! Let's just merge it then.

[steveklabnik]

@bors: r+ rollup

[bors]

📌 Commit efccd26 has been approved by steveklabnik

[steveklabnik]

I’m also starting to wonder why #25575 was not held to this same level of scrutiny.

Because I am an imperfect person. "This was reported upstream and will be addressed" + "one letter typo change" didn't trip my "What's the right way to make a substantial modification to a source you quoted at length" documentation writer brain.

[sferik]

"This was reported upstream and will be addressed" + "one letter typo change" didn't trip my "What's the right way to make a substantial modification to a source you quoted at length" documentation writer brain.

For what it’s worth, I’m also planning to report this upstream and hope that it will be addressed there as well.

[steveklabnik]

👍 ❤️

[stevencrockett]

I appreciate the intent here and certainly wish the world of engineering and computer science was less male-centric, but I don't see how anything should be gendered except for quotations, particularly if such a change is inconsistent with the style used elsewhere in the book (not sure if this is case).

Correcting a typo is clearly a win. In this case, simply switching genders is an opinionated choice that doesn't affect legibility or aid further understanding. Are there any guidelines on these type of changes in the docs for contributing? The intent for the PR is based on gender representation, but some people don't identfy with traditional masculinity or femininity either. Being gender-neutral seems like the most inclusive thing.

[sferik]

Correcting a typo is clearly a win. In this case, simply switching genders is an opinionated choice that doesn't affect legibility or aid further understanding.

Indeed, changing the gendered pronouns to female represents an opinionated choice. Likewise, not changing the gendered pronouns is an opinionated choice. That choice was made 30 years ago and has stood up until this point.

That history cannot be erased by pretending it never happened, shifting to neutral. Years of sexism have done profound and enduring harm to our community. The result is reflected in the Rust team page, which lists half as many members as it should. For every man on that page, there ought to be an empty square for a woman who was pushed out of the community, or discouraged not to get involved in the first place, because she received a continuous stream of cues that this is not a place for people like her.

This isn’t a theoretical problem and this isn’t a small problem. We should be acting quickly and dramatically to reverse this trend before one more potential programmer decides that she does not belong here.

This is a P0 critical issue!

It cannot be solved by this project alone and it will certainly not be solved by this pull request. This is literally the least we could do: not being actively exclusionary in an arbitrary example. Yet, somehow, this impossibly small step in the right direction encounters resistance, while another change—that breaches the integrity of the quote in the same manner—is merged without any debate for the sake of grammatical correctness: something we can all agree on.

[stevencrockett]

I'm not saying inaction is appropriate here. It should be changed for sure given we're now diverging from the exact quote. I don't agree that changing to gender-neutral is ignoring the issue, nor do I buy the argument that using females pronouns specifically is somehow correcting the wrongs of the past. I always try to treat anyone who I meet with equal respect regardless of gender, orientation etc. As far as I know, feminism is about true equality too. In any case, I simply think that the documentation should be objective and is the wrong venue for such activism.

I totally support other initiatives to engage the community though. The Rust communtiy seems to be friendly and accomodating anyway, but there should be more efforts to encourage women to get involved with Rust and open source development. As more people get involved and they become notable, they could get into one of the teams. It would be cool if there was a self-organised group for female Rustaceans, which given enough members could arrange meetups/hackathons. I could also imagine a Community/Diversity sub-team, especially as more and more people hopefully get into Rust now that it has reached 1.0. Having some visible members in the community for people to interact with who aren't straight white dudes is probably a good thing.

Anyway, I've said all I've got to say really. It's not my decision either way. Again, I appreciate your intent. :)

[bors]

☔️ The latest upstream changes (presumably #25605) made this pull request unmergeable. Please resolve the merge conflicts.

[sferik]

I have resolved the merge conflict by rebasing from the master branch. I realize this goes against @rust-highfive’s advice to make changes in extra commits but it seemed like the right thing to do.

Does the new ref (b748c2e) need to be approved for a rollup?

[steveklabnik]

@bors: r+ rollup

[bors]

📌 Commit b748c2e has been approved by steveklabnik

[steveklabnik]

And yeah, rebasing is the right thing in this case. Thanks!

[equality4all]

[Post removed by the Mod team.]

[erickt]

Since this is queued up for merging, it would be more appropriate to shift the diversity discussions to the internals thread

[Edit: Updated link. ~Manish]

[steveklabnik]

Note for anyone commenting on this old commit, this example no longer appears in the documentation at all, for unrelated reasons to this change.