[v2,1/4] Documentation: use singular they when appropriate

Commit Message

Derrick Stolee June 9, 2021, 1:54 p.m. UTC

From: Derrick Stolee <[e-mail]>

There are several instances in our documentation where we refer to an
anonymous user as "a contributor" or "an integrator" or similar. To
avoid repeating this role, pronouns are used. Previous examples
chose a gender for this user, using "he/him" or "she/her" arbitrarily.

Replace these uses with "they/them" to ensure that these documentation
examples apply to all potential users without exception.

Helped-by: Richard Kerry <[e-mail]>
Helped-by: Junio C Hamano <[e-mail]>
Signed-off-by: Derrick Stolee <[e-mail]>
---
 Documentation/SubmittingPatches | 8 ++++----
 Documentation/git-push.txt      | 4 ++--
 Documentation/user-manual.txt   | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

Comments

Felipe Contreras June 9, 2021, 3:33 p.m. UTC | #1

Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee <[e-mail]>
> Replace these uses with "they/them" to ensure that these documentation
> examples apply to all potential users without exception.

This is not the main purpose of documentation.

The main purpose is to convey useful information as accurately and
readably as possible.

> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -372,10 +372,10 @@ If you like, you can put extra tags at the end:
>    the patch attempts to fix.
>  . `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.
> +. `Reviewed-by:`, unlike the other tags, can only be offered by a
> +  reviewer when they are completely satisfied with the patch.  It is
> +  offered only after reviews by reviewers who are known to be experts
> +  in the affected area by the community members.

This is convoluted, but at least doesn't sound wrong.

> --- 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 they made a serious mistake, and decided to backtrack,

This suffers from the same problem "the reviewer" above did: it's
semantically singular. It doesn't sound grammatically right to many.

Another solution is to use an indefinite or generic noun: "they" -> "a".

  the developer may have realized a serious mistake was made

Of course it isn't a good style to use the passive voice, and we will be
counting on the reader assuming who made mistake. But at least it's
more grammatically correct than your version.

So far a step in the wrong direction.

Patch

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 55287d72e0ef..f519a8dfff7c 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -372,10 +372,10 @@  If you like, you can put extra tags at the end:
   the patch attempts to fix.
 . `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.
+. `Reviewed-by:`, unlike the other tags, can only be offered by a
+  reviewer when they are completely satisfied with the patch.  It is
+  offered only after reviews by reviewers who are known to be experts
+  in the affected area by the community members.
 . `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 a953c7c38790..2f25aa3a291b 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 f9e54b867417..4fe9be117c4a 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 they made a serious mistake, and decided to backtrack,
 resulting in a situation like:
 
 ................................................