@@ -551,6 +551,51 @@ Writing Documentation:
551
551
documentation, please see the documentation-related advice in the
552
552
Documentation/SubmittingPatches file).
553
553
554
+ In order to ensure the documentation is inclusive, avoid assuming
555
+ that an unspecified example person is male or female, and think
556
+ twice before using "he", "him", "she", or "her". Here are some
557
+ tips to avoid use of gendered pronouns:
558
+
559
+ - Prefer succinctness and matter-of-factly describing functionality
560
+ in the abstract. E.g.
561
+
562
+ --short:: Emit output in the short-format.
563
+
564
+ and avoid something like these overly verbose alternatives:
565
+
566
+ --short:: Use this to emit output in the short-format.
567
+ --short:: You can use this to get output in the short-format.
568
+ --short:: A user who prefers shorter output could....
569
+ --short:: Should a person and/or program want shorter output, he
570
+ she/they/it can...
571
+
572
+ This practice often eliminates the need to involve human actors in
573
+ your description, but it is a good practice regardless of the
574
+ avoidance of gendered pronouns.
575
+
576
+ - When it becomes awkward to stick to this style, prefer "you" when
577
+ addressing the the hypothetical user, and possibly "we" when
578
+ discussing how the program might react to the user. E.g.
579
+
580
+ You can use this option instead of --xyz, but we might remove
581
+ support for it in future versions.
582
+
583
+ while keeping in mind that you can probably be less verbose, e.g.
584
+
585
+ Use this instead of --xyz. This option might be removed in future
586
+ versions.
587
+
588
+ - If you still need to refer to an example person that is
589
+ third-person singular, you may resort to "singular they" to avoid
590
+ "he/she/him/her", e.g.
591
+
592
+ A contributor asks their upstream to pull from them.
593
+
594
+ Note that this sounds ungrammatical and unnatural to those who
595
+ learned that "they" is only used for third-person plural, e.g.
596
+ those who learn English as a second language in some parts of the
597
+ world.
598
+
554
599
Every user-visible change should be reflected in the documentation.
555
600
The same general rule as for code applies -- imitate the existing
556
601
conventions.
0 commit comments