| Message ID | afc51c5e6edec7935a6d0d0a05d396e11311ca6c.1623085069.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Use singular "they" when appropriate | expand |
On Mon, Jun 07 2021, Derrick Stolee via GitGitGadget wrote: > From: Derrick Stolee <dstolee@microsoft.com> > > 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. > > Signed-off-by: Derrick Stolee <dstolee@microsoft.com> I think this is mostly an improvement, however: > .../using-signed-tag-in-pull-request.txt | 38 +++++++++---------- This is a quote from a mail of Junio's[1] (date and all). I don't think it makes sense to copyedit that after the fact without at least editing the header that indicates that it's a verbatim reproduction. 1. https://lore.kernel.org/git/7vehuyosaa.fsf@alter.siamese.dyndns.org/
On 6/7/2021 1:09 PM, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Jun 07 2021, Derrick Stolee via GitGitGadget wrote: > >> From: Derrick Stolee <dstolee@microsoft.com> >> >> 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. >> >> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> > > I think this is mostly an improvement, however: > >> .../using-signed-tag-in-pull-request.txt | 38 +++++++++---------- > > This is a quote from a mail of Junio's[1] (date and all). I don't think > it makes sense to copyedit that after the fact without at least editing > the header that indicates that it's a verbatim reproduction. > > 1. https://lore.kernel.org/git/7vehuyosaa.fsf@alter.siamese.dyndns.org/ That's a good point. It does look a little strange that there is an email in our Documentation/ directory. I wondered if this was included in the docs that get posted to git-scm.com, but I see that the link I manually constructed [1] redirects to the GitHub mirror. [1] https://git-scm.com/docs/howto/using-signed-tag-in-pull-request.txt As long as this file remains formatted as an archived email message, the edits here are inappropriate. It's another question of whether the files within Documentation/howto should be updated to be docs that can be more easily posted in places like git-scm.com. For now, I'll remove these edits from the patch. Thanks, -Stolee
On 07/06/2021 19:32, Derrick Stolee wrote: > On 6/7/2021 1:09 PM, Ævar Arnfjörð Bjarmason wrote: >> >> On Mon, Jun 07 2021, Derrick Stolee via GitGitGadget wrote: >> >>> From: Derrick Stolee <dstolee@microsoft.com> >>> >>> 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. >>> >>> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> >> >> I think this is mostly an improvement, however: >> >>> .../using-signed-tag-in-pull-request.txt | 38 +++++++++---------- >> >> This is a quote from a mail of Junio's[1] (date and all). I don't think >> it makes sense to copyedit that after the fact without at least editing >> the header that indicates that it's a verbatim reproduction. >> >> 1. https://lore.kernel.org/git/7vehuyosaa.fsf@alter.siamese.dyndns.org/ > > That's a good point. It does look a little strange that there is > an email in our Documentation/ directory. I wondered if this was > included in the docs that get posted to git-scm.com, but I see that > the link I manually constructed [1] redirects to the GitHub mirror. > > [1] https://git-scm.com/docs/howto/using-signed-tag-in-pull-request.txt > > As long as this file remains formatted as an archived email message, > the edits here are inappropriate. To be fair, this file has already been copyedited once in commit 2de9b71138 (Documentation: the name of the system is 'Git', not 'git', 2013-01-21) > It's another question of whether the > files within Documentation/howto should be updated to be docs that can > be more easily posted in places like git-scm.com. > > For now, I'll remove these edits from the patch.
On Mon, Jun 07 2021, Derrick Stolee wrote: > On 6/7/2021 1:09 PM, Ævar Arnfjörð Bjarmason wrote: >> >> On Mon, Jun 07 2021, Derrick Stolee via GitGitGadget wrote: >> >>> From: Derrick Stolee <dstolee@microsoft.com> >>> >>> 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. >>> >>> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> >> >> I think this is mostly an improvement, however: >> >>> .../using-signed-tag-in-pull-request.txt | 38 +++++++++---------- >> >> This is a quote from a mail of Junio's[1] (date and all). I don't think >> it makes sense to copyedit that after the fact without at least editing >> the header that indicates that it's a verbatim reproduction. >> >> 1. https://lore.kernel.org/git/7vehuyosaa.fsf@alter.siamese.dyndns.org/ > > That's a good point. It does look a little strange that there is > an email in our Documentation/ directory. I wondered if this was > included in the docs that get posted to git-scm.com, but I see that > the link I manually constructed [1] redirects to the GitHub mirror. > > [1] https://git-scm.com/docs/howto/using-signed-tag-in-pull-request.txt We have a few of those FWIW, try grepping for ^Subject Documentation/ It seems git-scm.com dosen't carry them, but googling around e.g. this site does: https://gitirc.eu/howto/using-signed-tag-in-pull-request.html > As long as this file remains formatted as an archived email message, > the edits here are inappropriate. It's another question of whether the > files within Documentation/howto should be updated to be docs that can > be more easily posted in places like git-scm.com. *Nod*, I have some unrelated patches to fix some of this state of affairs in Documentation/, but for now it's like that... I do think there's a time & place for it though, and it's unfortunate that we haven't done as much of this recently. We've had quite a few "E-Mails of reference", and IMO we're better off with them in Documentation/ than not at all, and if we require that they be formatted into "normal" documentation we're probably closer to "not at all"...
Derrick Stolee via GitGitGadget wrote: > From: Derrick Stolee <dstolee@microsoft.com> > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -373,7 +373,7 @@ 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 > + reviewer and means that they are completely satisfied that the patch This sounds completely alien to me. Granted, I'm not a native English speaker, but aren't you supposed to be trying to be inclusive? It took me a considerable amount of time to train my mind to think in English, and now I don't have to think in Spanish, but "he" is "él", "she" is "ella", and "they" is "ellos", or "ellas". And that has been more than enough to read 99.9% of documents I encounter without problems. And now you come out of the blue with a pronoun that doesn't match any of my mental models. There's many Spanish speakers out there, but this probably extends to Italians, French, and all the other Latin-based languages. But to be honest I read a lot of English, and I virtually never encounter this usage. And at least 58% of the Usage Panel of The American Heritage Dictionary [1] agrees with me. I have read Steven Pinker's (a renowned linguist) style manual: The Sense of Style. He specifically mentions singular "they", and he explains the cases where it makes sense, and where it doesn't. It is not so straight-forward, and to show why, here's an example: A contemporary example with an unambiguous female referent comes from a spoken interview with Sean Ono Lennon in which he specified the kind of person he was seeking as a romantic partner: “Any girl who is interested must simply be born female and between the ages of 18 and 45. They must have an IQ above 130 and they must be honest.” In this case "they" is grammatically singular, yes, but it is *psychologically* plural, since the person is picked from a pool. I don't know how a native speaker parses this "they", but as a Spanish speaker I cannot leave it unspecified. "They must" translates to "deben", which is plural, if it was singular it would be "debe", which in English would be "she must". I have read many instances where English speakers argue it's a singular "they" but to me it's not. According to Steven Pinker it's because it's psychologically plural. Pinker uses singular "they" very occasionally, and only with semantically plural antecedents, the rest of the times he alternates between he and she freely. And I try to do so as well. This is his conclusion in his style manual: Because of these complexities, writers always have to consider the full inventory of devices that the English language makes available to convey generic information, each imperfect for a different reason: he, she, he or she, they, a plural antecedent, replacing the pronoun, and who knows, perhaps someday even using thon. For some purists, these complexities provide an excuse to dismiss all concerns with gender inclusiveness and stick with the flawed option of he. Gelernter complains, “Why should I worry about feminist ideology while I write? . . . Writing is a tricky business that requires one’s whole concentration.” But the reaction is disingenuous. Every sentence requires a writer to grapple with tradeoffs between clarity, concision, tone, cadence, accuracy, and other values. Why should the value of not excluding women be the only one whose weight is set to zero? He does however, provide tips to avoid some hurdles, one is to express quantified descriptions as plural, so we would have: `Reviewed-by:`, unlike the other tags, can only be offered by the reviewers and means that they are completely satisfied that the patch is ready for application. It is usually offered only after a detailed review. That reads perfectly fine to me. > --- 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 one does read correctly to me, and is in fact better than "she". And it is because "somebody" is semantically plural: he or she comes from a pool of people. As stated above, writing is a tricky business, you can't just s/s?he/they/. Not even renowned linguists dare to prescribe point-blank rules like you are trying to do. This is part of Usage Note on "singular they" from The American Heritage Dictionary: Resistance remains strongest when the sentence refers to a specific individual whose gender is unknown, rather than to a generic individual representative of anyone: in our 2015 survey, 58 percent of the Panel found We thank the anonymous reviewer for their helpful comments unacceptable. A sentence with a generic antecedent, A person at that level should not have to keep track of the hours they put in, was rejected by 48 percent (a substantial change from our 1996 survey, in which 80 percent rejected this same sentence). As for the use of they with antecedents such as anyone and everyone, pronouns that are grammatically singular but carry a plural meaning, by 2008, a majority of the Panel accepted such sentences as If anyone calls, tell them I can’t come to the phone (56 percent) and Everyone returned to their seats (59 percent). I do not think the Git project should jump into these muddy waters. Cheers. [1] https://ahdictionary.tumblr.com/post/147597257733/updated-usage-note-they
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index 55287d72e0ef..b518d3157f70 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -373,7 +373,7 @@ 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 > + reviewer and means that they are completely satisfied that the patch All the other changes in this step, including the one that is a quote of past e-mail sent to the list, didn't sound so awkward and good, but this one does sound strange for this non-native speaker. Granted, the use of "she" here is already awkward (in the sense "why do we assume that the reviewer is of certain gender?"), but "they" looks ungrammatical on top of that awkwardness. `Reviewed-by:`, unlike the other tags, can only be offered by reviewers themselves when they are completely satisified with the patch. It is offered only after a detailed review by reviewers who are known to be experts in the affected area by the community members. perhaps?
Or:
`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.
Sentence one uses singular they to refer to one of a pool of reviewers.
In the second all items are plural.
Regards,
Richard.
-----Original Message-----
From: Junio C Hamano <gitster@pobox.com>
Sent: 08 June 2021 02:19
To: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org; sandals@crustytoothpaste.net; stolee@gmail.com; jrnieder@gmail.com; emilyshaffer@google.com; Derrick Stolee <derrickstolee@github.com>; Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH 1/4] Documentation: use singular they when appropriate
Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> diff --git a/Documentation/SubmittingPatches
> b/Documentation/SubmittingPatches index 55287d72e0ef..b518d3157f70
> 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -373,7 +373,7 @@ 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
> + reviewer and means that they are completely satisfied that the
> + patch
All the other changes in this step, including the one that is a quote of past e-mail sent to the list, didn't sound so awkward and good, but this one does sound strange for this non-native speaker.
Granted, the use of "she" here is already awkward (in the sense "why do we assume that the reviewer is of certain gender?"), but "they"
looks ungrammatical on top of that awkwardness.
`Reviewed-by:`, unlike the other tags, can only be offered by
reviewers themselves when they are completely satisified with
the patch. It is offered only after a detailed review by
reviewers who are known to be experts in the affected area by
the community members.
perhaps?
On Mon, Jun 07, 2021 at 04:57:45PM +0000, Derrick Stolee via GitGitGadget wrote: > > > 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. (I am not disagreeing with the series.) There is value in intentionally defaulting to "she/her", especially in settings where women are underrepresented. It can be a nice way to shake the foundations of unconscious bias in the reader's head. See https://www.askamanager.org/2011/07/why-i-refer-to-everyone-as-she.html as an example. > Replace these uses with "they/them" to ensure that these documentation > examples apply to all potential users without exception. However, in this case, I think "they/them" is appropriate as a default. As you say, this documentation is intended as a guide to potential users and contributors, and should apply to them. Thanks for writing the change. Reviewed-by: Emily Shaffer <emilyshaffer@google.com>
Emily Shaffer wrote: > On Mon, Jun 07, 2021 at 04:57:45PM +0000, Derrick Stolee via GitGitGadget wrote: > > Replace these uses with "they/them" to ensure that these documentation > > examples apply to all potential users without exception. > > However, in this case, I think "they/them" is appropriate as a default. > As you say, this documentation is intended as a guide to potential users > and contributors, and should apply to them. Thanks for writing the > change. What do you prefer? A. We thank the reviewer for their helpful comments B. We thank the reviewer for her helpful comments
"Kerry, Richard" <richard.kerry@atos.net> writes: > Or: > > `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. > > Sentence one uses singular they to refer to one of a pool of reviewers. > In the second all items are plural. Yeah, it reads well, I'd think.
Emily Shaffer <emilyshaffer@google.com> writes: > There is value in intentionally defaulting to "she/her", especially in > settings where women are underrepresented. It can be a nice way to > shake the foundations of unconscious bias in the reader's head. Heh, I used to refer to a hypothethical user in my writing as a female and a male on alternate days (Tuesdays and Thursdays were male day). It quickly got confusing when I had to compose my reply on an even day to a response to my earlier message that was written on an odd day, and I had to abandon the practice ;-)
On 6/8/2021 7:21 PM, Junio C Hamano wrote: > "Kerry, Richard" <richard.kerry@atos.net> writes: > >> Or: >> >> `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. >> >> Sentence one uses singular they to refer to one of a pool of reviewers. >> In the second all items are plural. > > Yeah, it reads well, I'd think. I agree. Thanks! -Stolee
What do you prefer? A. We thank the reviewer for their helpful comments B. We thank the reviewer for her helpful comments [RK] If this is, as it appears to be, a reference to a specific reviewer, then use their preferred pronoun, or possibly a conventional singular one if you know their name and they haven't specified a preference. [RK] Only if they aren't known, and especially if they are one from a pool, then "their". [RK] Or make them plural - We thank the reviewers for their helpful comments. [RK] Or rephrase to sidestep the issue (though it isn't clear to me here what that option would be) Regards, Richard.
Kerry, Richard wrote: > What do you prefer? > > A. We thank the reviewer for their helpful comments > B. We thank the reviewer for her helpful comments > > [RK] If this is, as it appears to be, a reference to a specific reviewer, then use their preferred pronoun, or possibly a conventional singular one if you know their name and they haven't specified a preference. > [RK] Only if they aren't known, and especially if they are one from a pool, then "their". > [RK] Or make them plural - We thank the reviewers for their helpful comments. > [RK] Or rephrase to sidestep the issue (though it isn't clear to me here what that option would be) The question is not what sort of rules you would like us to enforce (I for one don't believe in policing speech). The question is what you as a native English speaker, or non-native speaker, think of the sentences as they are. Do they sound grammatically correct to you? Would it be possible for you to use quoted line prefix [1] as is common on this mailing list? We only have the beginnings of a mailing list etiquette [2], but this is something that reads very different from everyone else. Cheers. [1] https://en.wikipedia.org/wiki/Posting_style#Quoted_line_prefix [2] https://lore.kernel.org/git/20210512233412.10737-1-dwh@linuxprogrammer.org/
Felipe Contreras <felipe.contreras@gmail.com> writes: > Derrick Stolee via GitGitGadget wrote: >> From: Derrick Stolee <dstolee@microsoft.com> >> --- a/Documentation/SubmittingPatches >> +++ b/Documentation/SubmittingPatches >> @@ -373,7 +373,7 @@ 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 >> + reviewer and means that they are completely satisfied that the patch Say wait a minute. If that is a "singular they", then why was the "is" changed to "are"? I think that belies the fact that there is no such thing as a "singular they".
Phillip Susi wrote: > > Felipe Contreras <felipe.contreras@gmail.com> writes: > > > Derrick Stolee via GitGitGadget wrote: > >> From: Derrick Stolee <dstolee@microsoft.com> > >> --- a/Documentation/SubmittingPatches > >> +++ b/Documentation/SubmittingPatches > >> @@ -373,7 +373,7 @@ 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 > >> + reviewer and means that they are completely satisfied that the patch > > Say wait a minute. If that is a "singular they", then why was the "is" > changed to "are"? Great point. I doubt any linguist would be happy with: can only be offered by the reviewer and means that they is completely satisfied... Unless we are in the context of African-American Vernacular English. > I think that belies the fact that there is no such thing as a > "singular they". There is such a thing as singular they, but it's not what the proponents of this patch think [1]: This is a good use of singular they: Everyone returned to their seats This isn't: We thank the anonymous reviewer for their helpful comments Cheers. [1] https://ahdictionary.tumblr.com/post/147597257733/updated-usage-note-they
Junio C Hamano <gitster@pobox.com> writes: > "Kerry, Richard" <richard.kerry@atos.net> writes: > >> Or: >> >> `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. >> >> Sentence one uses singular they to refer to one of a pool of reviewers. >> In the second all items are plural. > > Yeah, it reads well, I'd think. Actually, I take half of it back. The first sentence can talk about reviewers (not just a single reviewer), which would naturally match the pronoun "they", which would be even better. After all, more people looking at patches is a good thing ;-)
Hi Ævar, On Mon, 7 Jun 2021, Ævar Arnfjörð Bjarmason wrote: > On Mon, Jun 07 2021, Derrick Stolee via GitGitGadget wrote: > > > .../using-signed-tag-in-pull-request.txt | 38 +++++++++---------- > > This is a quote from a mail of Junio's[1] (date and all). I don't think > it makes sense to copyedit that after the fact without at least editing > the header that indicates that it's a verbatim reproduction. > > 1. https://lore.kernel.org/git/7vehuyosaa.fsf@alter.siamese.dyndns.org/ We edit those documents all the time, e.g. when `pu` was renamed to `seen`. And I think it is appropriate to edit them: as soon as those emails were copied into a version-controlled repository, we implicitly indicated our intention to iterate on them. Why else would we need to version-control them, after all. And it is desirable to edit them, too. If we truly want to be welcoming and inviting (especially to potential contributors who currently feel underrepresented), we need to model the language in our documentation accordingly. And I want to believe that we truly want to be welcoming like that. Ciao, Dscho
Hi Emily, On Tue, 8 Jun 2021, Emily Shaffer wrote: > There is value in intentionally defaulting to "she/her", especially in > settings where women are underrepresented. It can be a nice way to shake > the foundations of unconscious bias in the reader's head. See > https://www.askamanager.org/2011/07/why-i-refer-to-everyone-as-she.html > as an example. I am glad you brought this up. It is all too easy for male readers such as myself to not even notice how effortless it is to read text that includes you, whether by the pronoun "he" or by avoiding any gendered pronoun altogether. All the more surprising that the same male readers (again, I will include myself as it still happens to me, despite all the work I embarked on to become more conscious of my own biases) will stumble over sentences where a female pronoun "excludes" them. And the first reaction, funnily enough, is rarely "Oh, _that_ is how I make half of the population feel all the time!". Instead it is more like "How dare they exclude me"? Funny side note: this is precisely what happened recently in Germany, where a law was proposed, and in contrast to common practices (which dictates to use the "generic male form", i.e. "he/him", as the German language does not have a singular "they"), it used the "generic female" instead. I bet you can imagine the indignant backlash from male politicians... Let me be the first to admit that working on this kind of bias isn't easy, and I imagine that other male readers' struggles will be similar (or even more pronounced, if they are less interested in biases and fairness than I am). Seeing how threatening these efforts to adjust our language are sometimes perceived, I often find it pretty difficult to tread carefully. For example, I recently suggested that stumbling over a "singular they" might give male readers an opportunity to develop empathy with the underrepresented, to experience a glimpse of what it means to feel excluded (even if they weren't excluded at all), and consequently to pay more attention. This suggestion did not quite have the intended effect, I must say: it seems that this invitation was misunderstood as an attack instead. In light of this experience, even if I generally agree with your point about using "she/he" by default, I believe that Stolee's direction is more diplomatic. > On Mon, Jun 07, 2021 at 04:57:45PM +0000, Derrick Stolee via GitGitGadget wrote: > > > Replace these uses with "they/them" to ensure that these documentation > > examples apply to all potential users without exception. > > However, in this case, I think "they/them" is appropriate as a default. > As you say, this documentation is intended as a guide to potential users > and contributors, and should apply to them. Thanks for writing the > change. For what it's worth, I agree. Thank you, Stolee! Ciao, Dscho
Johannes Schindelin wrote: > And it is desirable to edit them, too. If we truly want to be welcoming > and inviting (especially to potential contributors who currently feel > underrepresented), we need to model the language in our documentation > accordingly. Whether or not this particular approach is how we want to model the language in our documentation is a matter for debate.
Johannes Schindelin wrote: > It is all too easy for male readers such as myself to not even notice how > effortless it is to read text that includes you, whether by the pronoun > "he" or by avoiding any gendered pronoun altogether. I am a male reader, and I have no problem reading "she", as many other (presumably male) readers have stated as well. > In light of this experience, even if I generally agree with your point about > using "she/he" by default, I believe that Stolee's direction is more > diplomatic. Except in diplomacy you are supposed to work with your counterpart, not completely ignore it. *Nobody* has a problem with using "she/her" in the documentation, and yet you push for the option guaranteed to increase conflict. That the opposite of diplomacy.
On 6/9/2021 2:47 PM, Phillip Susi wrote: > > Felipe Contreras <felipe.contreras@gmail.com> writes: > >> Derrick Stolee via GitGitGadget wrote: >>> From: Derrick Stolee <dstolee@microsoft.com> >>> --- a/Documentation/SubmittingPatches >>> +++ b/Documentation/SubmittingPatches >>> @@ -373,7 +373,7 @@ 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 >>> + reviewer and means that they are completely satisfied that the patch > > Say wait a minute. If that is a "singular they", then why was the "is" > changed to "are"? I think that belies the fact that there is no such > thing as a "singular they". Singular "they" works the same as singular "you". For example: ...means that _you are_ completely satisfied... Singular "you" had a similar backlash in the 1660s as singular "they" is having in this thread, but singular "you" has lasted (and we use "thou" only to signify someone using old-timey language). There is more of this in [1] and [2] [1] https://public.oed.com/blog/a-brief-history-of-singular-they/ [2] https://en.wikipedia.org/wiki/T%E2%80%93V_distinction#English Thanks, -Stolee
Derrick Stolee <stolee@gmail.com> writes: > Singular "they" works the same as singular "you". For example: > > ...means that _you are_ completely satisfied... > > Singular "you" had a similar backlash in the 1660s as singular "they" > is having in this thread, but singular "you" has lasted (and we use > "thou" only to signify someone using old-timey language). > > There is more of this in [1] and [2] > > [1] https://public.oed.com/blog/a-brief-history-of-singular-they/ > [2] https://en.wikipedia.org/wiki/T%E2%80%93V_distinction#English Thanks for references. [1] was an amusing and illuminating read. ... Anyone who said thou and thee was seen as a fool and an idiot, or a Quaker, or at least hopelessly out of date. Singular you has become normal and unremarkable. Also unremarkable are the royal we and, in countries without a monarchy, the editorial we: first-person plurals used regularly as singulars and nobody calling anyone an idiot and a fool. And singular they is well on its way to being normal and unremarkable as well.
Felipe Contreras <felipe.contreras@gmail.com> writes: > This is a good use of singular they: > > Everyone returned to their seats Shouldn't seat be singular there so that it agrees in number with the singular their?
Derrick Stolee wrote: > Singular "you" had a similar backlash in the 1660s as singular "they" > is having in this thread, but singular "you" has lasted (and we use > "thou" only to signify someone using old-timey language). > > There is more of this in [1] and [2] > > [1] https://public.oed.com/blog/a-brief-history-of-singular-they/ Let's see... In modern English, that’s: ‘Each man hurried . . . till they drew near . . . where William and his darling were lying together.’ Yeah, that grammatical singular "they" indeed, but with a semantic plural antecedent, so no, that's not what you are proposing above. I'd say leave linguistics to linguists.
Phillip Susi wrote: > > Felipe Contreras <felipe.contreras@gmail.com> writes: > > > This is a good use of singular they: > > > > Everyone returned to their seats > > Shouldn't seat be singular there so that it agrees in number with the > singular their? Good point. I do not know, and I didn't pick the example; the American Heritage Dictionary did. Translated into Spansih both uses would be correct "seat" or "seats" (except "seat" wouldn't have "their", but the equivalent of "his/her"). Anyway, even though I don't mind talking about this, I don't think this mailing list is the place for that. The git documentation has many problems, but heavily using gendered pronouns isn't one of them. Cheers.
Derrick Stolee <stolee@gmail.com> writes: > Singular "they" works the same as singular "you". For example: > > ...means that _you are_ completely satisfied... > > Singular "you" had a similar backlash in the 1660s as singular "they" > is having in this thread, but singular "you" has lasted (and we use > "thou" only to signify someone using old-timey language). Oh weird... the big debate with you always was that we have no plural version of it to use when referring to a group of people, and it was plural all along, but is still used when referring to only one person.
On Thu, Jun 10, 2021 at 10:18:11AM +0200, Johannes Schindelin wrote: > Hi Emily, > > On Tue, 8 Jun 2021, Emily Shaffer wrote: > > > There is value in intentionally defaulting to "she/her", especially in > > settings where women are underrepresented. It can be a nice way to shake > > the foundations of unconscious bias in the reader's head. See > > https://www.askamanager.org/2011/07/why-i-refer-to-everyone-as-she.html > > as an example. > > I am glad you brought this up. > > It is all too easy for male readers such as myself to not even notice how > effortless it is to read text that includes you, whether by the pronoun > "he" or by avoiding any gendered pronoun altogether. > > All the more surprising that the same male readers (again, I will include > myself as it still happens to me, despite all the work I embarked on to > become more conscious of my own biases) will stumble over sentences where > a female pronoun "excludes" them. > > And the first reaction, funnily enough, is rarely "Oh, _that_ is how I > make half of the population feel all the time!". Instead it is more like > "How dare they exclude me"? Funnily enough, I was also in such a situation, and as I explained in another email in this thread, I /didn't even notice until the very end/, at which I didn't mind at all, but made a joke about it and the answer implied that I'm some kind of sexist, which was deeply insulting to me. > > Funny side note: this is precisely what happened recently in Germany, > where a law was proposed, and in contrast to common practices (which > dictates to use the "generic male form", i.e. "he/him", as the German > language does not have a singular "they"), it used the "generic female" > instead. I bet you can imagine the indignant backlash from male > politicians... Right, that's because there is no "generic femininum", it is a feminist invention that didn't quite catch on, and not without reason. It is a solution looking to create problems. (I live in Germany) I've listened to how real people talk "on the streets" and my experience is that they use the generic masculinum, whether the speaker is male or female. Pretty much the only place I see people gender their speech is on TV and in academia. And, "funnily enough", they do so heavily inconsistently, as that is impossible to do consistently, if the point is to actually convey information and not neuro-linguistic programming. The reason why the generic masculinum is the default is that in our minds it is a no-op, and that's not because there is some kind of conspiracy against non-males, but because nobody actually cares about sex, because it is a completely irrelevant detail. The only way I can see why someone would even notice the sex, is that he actually cares about the sex. However, if you use the female form, the brain will stumble. Not because the listener is angry because females should not be spoken to or about, but because it trips the brain's pattern recognition. Isn't it "funny" how we listen up when a female is mentioned, but nobody cares when the male is mentioned? So if the male politicians backlashed on using a "generic femininum", they were very right to do so; males have to share their gender with everyone, females have their own exclusive gender. One might even dare to assert that males do not actually have their own gender at all in the first place. Cheers, Robert Karszniewicz
> From: Felipe Contreras <felipe.contreras@gmail.com> > Sent: 09 June 2021 18:45 > Subject: RE: [PATCH 1/4] Documentation: use singular they when appropriate > > > [RK] Or rephrase to sidestep the issue > > Would it be possible for you to use quoted line prefix [1] as is common on > this mailing list? We only have the beginnings of a mailing list etiquette [2], > but this is something that reads very different from everyone else. Sorry. Yes. Will do. When I first looked for reply options In Outlook I couldn't find "indent with prefix". I've just looked again and found it. Though it is still giving me "[RK}" on new lines, so I need another look to get that turned off. Regards, Richard.
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 55287d72e0ef..b518d3157f70 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -373,7 +373,7 @@ 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 + reviewer and means that they are completely satisfied that the patch is ready for application. It is usually offered only after a detailed review. . `Tested-by:` is used to indicate that the person applied the patch 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/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt index bbf040eda8af..e9ad0b4ff8e0 100644 --- a/Documentation/howto/using-signed-tag-in-pull-request.txt +++ b/Documentation/howto/using-signed-tag-in-pull-request.txt @@ -1,8 +1,8 @@ From: Junio C Hamano <gitster@pobox.com> Date: Tue, 17 Jan 2011 13:00:00 -0800 Subject: Using signed tag in pull requests -Abstract: Beginning v1.7.9, a contributor can push a signed tag to her - publishing repository and ask her integrator to pull it. This assures the +Abstract: Beginning v1.7.9, a contributor can push a signed tag to their + publishing repository and ask their integrator to pull it. This assures the integrator that the pulled history is authentic and allows others to later validate it. Content-type: text/asciidoc @@ -11,9 +11,9 @@ How to use a signed tag in pull requests ======================================== A typical distributed workflow using Git is for a contributor to fork a -project, build on it, publish the result to her public repository, and ask -the "upstream" person (often the owner of the project where she forked -from) to pull from her public repository. Requesting such a "pull" is made +project, build on it, publish the result to their public repository, and ask +the "upstream" person (often the owner of the project where they forked +from) to pull from their public repository. Requesting such a "pull" is made easy by the `git request-pull` command. Earlier, a typical pull request may have started like this: @@ -32,7 +32,7 @@ followed by a shortlog of the changes and a diffstat. The request was for a branch name (e.g. `for-xyzzy`) in the public repository of the contributor, and even though it stated where the -contributor forked her work from, the message did not say anything about +contributor forked their work from, the message did not say anything about the commit to expect at the tip of the for-xyzzy branch. If the site that hosts the public repository of the contributor cannot be fully trusted, it was unnecessarily hard to make sure what was pulled by the integrator was @@ -57,7 +57,7 @@ integrator, using Git v1.7.9 or later. A contributor or a lieutenant ----------------------------- -After preparing her work to be pulled, the contributor uses `git tag -s` +After preparing their work to be pulled, the contributor uses `git tag -s` to create a signed tag: ------------ @@ -73,7 +73,7 @@ to justify why it is worthwhile for the integrator to pull it, as this message will eventually become part of the final history after the integrator responds to the pull request (as we will see later). -Then she pushes the tag out to her public repository: +Then they push the tag out to their public repository: ------------ $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy @@ -94,10 +94,10 @@ The contributor then prepares a message to request a "pull": The arguments are: -. the version of the integrator's commit the contributor based her work on; -. the URL of the repository, to which the contributor has pushed what she - wants to get pulled; and -. the name of the tag the contributor wants to get pulled (earlier, she could +. the version of the integrator's commit the contributor based their work on; +. the URL of the repository, to which the contributor has pushed what they + want to get pulled; and +. the name of the tag the contributor wants to get pulled (earlier, they could write only a branch name here). The resulting msg.txt file begins like so: @@ -130,7 +130,7 @@ command, the reader should notice that: The latter is why the contributor would want to justify why pulling her work is worthwhile when creating the signed tag. The contributor then -opens her favorite MUA, reads msg.txt, edits and sends it to her upstream +opens their favorite MUA, reads msg.txt, edits and sends it to their upstream integrator. @@ -163,20 +163,20 @@ In the editor, the integrator will see something like this: Notice that the message recorded in the signed tag "Completed frotz feature" appears here, and again that is why it is important for the -contributor to explain her work well when creating the signed tag. +contributor to explain their work well when creating the signed tag. As usual, the lines commented with `#` are stripped out. The resulting commit records the signed tag used for this validation in a hidden field so that it can later be used by others to audit the history. There is no -need for the integrator to keep a separate copy of the tag in his +need for the integrator to keep a separate copy of the tag in their repository (i.e. `git tag -l` won't list the `frotz-for-xyzzy` tag in the -above example), and there is no need to publish the tag to his public +above example), and there is no need to publish the tag to their public repository, either. -After the integrator responds to the pull request and her work becomes +After the integrator responds to the pull request and their work becomes part of the permanent history, the contributor can remove the tag from -her public repository, if she chooses, in order to keep the tag namespace -of her public repository clean, with: +their public repository, if they choose, in order to keep the tag namespace +of their public repository clean, with: ------------ $ git push example.com:/git/froboz.git :frotz-for-xyzzy 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: ................................................