| Message ID | 20210611202819.47077-2-felipe.contreras@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Avoid gender pronouns | expand |
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
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 --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: ................................................
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(-)