On Tue, Jun 15 2021, Derrick Stolee via GitGitGadget wrote:
> [...]
> * References to fictional people with clear genders (e.g. Alice and
> Bob).
I mentioned in the feedback on an earlier round[1] that aside from your
goals, these would be better rewritten. I've just submitted a series[2]
to do that; perhaps you can look at that and see if you think there's
still a reason to explicitly exclude these.
> * Sample text used in test cases (e.g t3702, t6432).
FWIW that's another unaddressed-by-you question I had in an earlier
round[1].
> [...]
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index e3af089ecf26..0282f836548a 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -551,6 +551,34 @@ Writing Documentation:
> documentation, please see the documentation-related advice in the
> Documentation/SubmittingPatches file).
>
> + In order to ensure the documentation is inclusive, avoid assuming
> + that an unspecified example person is male or female, and think
> + twice before using "he", "him", "she", or "her". Here are some
> + tips to avoid use of gendered pronouns:
> +
> + - Removing the example person might make the sentence more
> + clear and efficient. Instead of saying "The programmer
> + chooses between X and Y as she sees fit", it is clearer to
> + say "Valid choices are X and Y".
> +
> + - If you need to talk about an example person, then try using
> + second-person to allow the reader to be that example. For
> + example, "If you want X to happen, you'd pass option Y",
> + instead of "If the user wants X to happen, she'd ...").
> + Alternatively, replace the single example with more than one
> + person and use plural "they", such as "Interested readers
> + can read 'git log -p README' to learn the history in their
> + ample spare time" instead of "an interested reader" learning
> + in "his" spare time).
> +
> + - If you absolutely need to refer to an example person that is
> + third-person singluar, you may resort to "singular they" (e.g.
> + "A contributor asks their upstream to pull from them"). Note
> + that this sounds ungrammatical and unnatural to those who
> + learned English as a second language in some parts of the
> + world, so should be avoided unless the earlier techniques
> + fail to improve the sentence.
> +
> Every user-visible change should be reflected in the documentation.
> The same general rule as for code applies -- imitate the existing
> conventions.
In the same E-Mail that you copied the original version of this new text
from[3], Junio suggested, mostly in reference to my [4]:
I tend to agree that Ævar's approach to guidelines is to cover more
general readability tips, not necessarily focusing on avoidance of
gendered pronouns, let alone encouraging of "singular they". I
think that is overall a good approach to advance the "let's make
sure the document is easier to read by everybody" goal than
mechanical "he and she are bad, let's use they" does.
To be fair he does go on to say something that suggests to also go for a
version of your approach here, i.e. that we still have some reference to
"they" over "he" and "she". I've got no problem with that, but he also
said (comments in [] are mine):
If we were to go that route [(of copying Junio's version from [3])],
I think the first two points [(i.e. the first two bullet-points you
incorporated above)] (which I didn't give enough thought to be even
called a "draft") should be replaced with something like what Ævar
wrote in his write-up.
So your version here does none of that, and we're mostly left with advice
about what not to do in the demonstrably obscure edge case of gendered
language in our docs (as evidenced by the diffstat).
But we aren't helping contributors much with with positive examples of
what to do unrelated to that, i.e. for documentation they could actually
be expected to write or maintain. I.e. general prose guidelines for
common the cases of discussing command-line options, program behavior,
user interaction etc.
Anyway, I don't think I'll be participating in this topic any
further. It seems you're not interested in pursuing alternate approaches
that accomplish your goals, or in responding to specific point-by-point
feedback on your series from myself and others.
I do think it would be a much better and respectful use of everyone's
time on this ML if you clearly stated your unwillingness to deviate from
the narrow approach in the initial version of a series you're
submitting.
Maybe I'm wrong and you are willing to incorporate something like more
general prose that accomplishes most or all of your narrow goals as a
side-effect, but right now it seems you're not.
If we're going to make some use of the collective time spent by a lot of
people on-list reading the documentation you're suggesting to change,
that'll have to be done in a series that would textually conflict with
yours (and which Junio would need to clean up), or in something that
would build on top of your more narrowly focused work.
1. https://lore.kernel.org/git/875yyp4fun.fsf@xxxxxxxxxxxxxxxxxxx/
2. https://lore.kernel.org/git/cover-0.6-00000000000-20210615T161330Z-avarab@xxxxxxxxx/
3. https://lore.kernel.org/git/xmqqr1h51dce.fsf@gitster.g/
4. https://lore.kernel.org/git/87a6nz2fda.fsf@xxxxxxxxxxxxxxxxxxx/
