diff mbox series

[1/2] doc: avoid using the gender of other people

Message ID 20210611202819.47077-2-felipe.contreras@gmail.com (mailing list archive)
State New
Headers show
Series Avoid gender pronouns | expand

Commit Message

Felipe Contreras June 11, 2021, 8:28 p.m. UTC
Some people have a problem with using a female reviewer or a female
developer as an example, and since this is an irrelevant detail, let's
say goodbye to our illustrative female colleagues.

Inspired-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/SubmittingPatches | 5 ++---
 Documentation/git-push.txt      | 4 ++--
 Documentation/user-manual.txt   | 2 +-
 3 files changed, 5 insertions(+), 6 deletions(-)

Comments

Derrick Stolee June 15, 2021, 1:28 p.m. UTC | #1
On 6/11/2021 4:28 PM, Felipe Contreras wrote:
> Some people have a problem with using a female reviewer or a female
> developer as an example, and since this is an irrelevant detail, let's
> say goodbye to our illustrative female colleagues.

I find this message to be snarky and underhanded instead of
actually describing the goals at hand. Citing the reason as
stated is _not_ the purpose of these gender-neutral
recommendations.

Instead, a message such as this could apply:

  Using gendered pronouns for an anonymous person applies a
  gender where none is known, and further excludes readers
  who do not use gendered pronouns. Avoid such examples in
  the documentation by using "they" or passive voice to
  avoid the need for a pronoun.

The textual edits in the patch are correct.

-Stolee
Felipe Contreras June 15, 2021, 4:30 p.m. UTC | #2
Derrick Stolee wrote:
> On 6/11/2021 4:28 PM, Felipe Contreras wrote:
> > Some people have a problem with using a female reviewer or a female
> > developer as an example, and since this is an irrelevant detail, let's
> > say goodbye to our illustrative female colleagues.
> 
> I find this message to be snarky and underhanded instead of
> actually describing the goals at hand.

But it is accurate.

I have no problem when I read a text that uses a female reviwer as an
illustration. Apparently you do, and presumably others.

> Citing the reason as stated is _not_ the purpose of these
> gender-neutral recommendations.

I believe the purpose is to tailor the wording to you.

> Instead, a message such as this could apply:
> 
>   Using gendered pronouns for an anonymous person applies a
>   gender where none is known, and further excludes readers
>   who do not use gendered pronouns.

It doesn't exclude the readers who do not use genedered pronouns.

Anna--a Finnish reader--may not use gendered pronouns herself, that
doesn't mean she automatically would have a problem when reading "she"
or "he", nor that she would feel excluded.


This patch is not for Anna--who has no problem reading an illustration
in English which uses a female colleague as illustration--this patch is
for you.

Cheers.
diff mbox series

Patch

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 55287d72e0..3e215f4d80 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -373,9 +373,8 @@  If you like, you can put extra tags at the end:
 . `Acked-by:` says that the person who is more familiar with the area
   the patch attempts to modify liked the patch.
 . `Reviewed-by:`, unlike the other tags, can only be offered by the
-  reviewer and means that she is completely satisfied that the patch
-  is ready for application.  It is usually offered only after a
-  detailed review.
+  reviewers themselves when they are completely satisfied with the
+  patch after a detailed analysis.
 . `Tested-by:` is used to indicate that the person applied the patch
   and found it to have the desired effect.
 
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index a953c7c387..2f25aa3a29 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -244,8 +244,8 @@  Imagine that you have to rebase what you have already published.
 You will have to bypass the "must fast-forward" rule in order to
 replace the history you originally published with the rebased history.
 If somebody else built on top of your original history while you are
-rebasing, the tip of the branch at the remote may advance with her
-commit, and blindly pushing with `--force` will lose her work.
+rebasing, the tip of the branch at the remote may advance with their
+commit, and blindly pushing with `--force` will lose their work.
 +
 This option allows you to say that you expect the history you are
 updating is what you rebased and want to replace. If the remote ref
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f9e54b8674..96240598e3 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2792,7 +2792,7 @@  A fast-forward looks something like this:
 
 In some cases it is possible that the new head will *not* actually be
 a descendant of the old head.  For example, the developer may have
-realized she made a serious mistake, and decided to backtrack,
+realized a serious mistake was made and decided to backtrack,
 resulting in a situation like:
 
 ................................................