Commit Message
I've committed this change to use gneder agnostic pronouns on the
non-historical web documents.
and if you're upset that Those Are Plural!, assemble this URL and watch
youtube /watch?v=46ehrFk-gLk&t=87s at about the 2 minute mark
nathan
From b5a0f250f0f05364a51c331d040d78bf15057884 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell <nathan@acm.org>
Date: Tue, 30 Nov 2021 07:12:44 -0500
Subject: [PATCH] Use gender-agnostic pronouns
Use they/them/their in non-historical documents
---
htdocs/bugs/management.html | 6 +++---
htdocs/contribute.html | 2 +-
htdocs/develop.html | 2 +-
htdocs/fortran/index.html | 4 ++--
htdocs/gitwrite.html | 2 +-
5 files changed, 8 insertions(+), 8 deletions(-)
@@ -203,7 +203,7 @@ fixing (the rationale is that a patch will have to go to the newest
release branch before any other release branch).
The priority of a regression should initially be set to P3.
The milestone and the priority can
-be changed by the release manager and his/her delegates.</p>
+be changed by the release manager and their delegates.</p>
<p><strong>If a patch fixing a PR has been submitted</strong>, a link
to the message with the patch should be added to the PR, as well as the
@@ -224,8 +224,8 @@ release versions) should get "minor" severity and the additional keyword
<p><strong>Bugs in component "bootstrap"</strong> that refer to older
releases or snapshots/CVS versions should be put into state "WAITING",
-asking the reporter whether she can still reproduce the problem and to
-report her findings in any case (whether positive or negative).</p>
+asking the reporter whether they can still reproduce the problem and to
+report their findings in any case (whether positive or negative).</p>
<ul>
<li>If the response is "works now", close the report,</li>
@@ -397,7 +397,7 @@ to point out lack of write access in your initial submission, too.</p>
<h2 id="announce">Announcing Changes (to our Users)</h2>
-<p>Everything that requires a user to edit his Makefiles or his source code
+<p>Everything that requires a user to edit their Makefiles or source code
is a good candidate for being mentioned in the release notes.</p>
<p>Larger accomplishments, either as part of a specific project, or long
@@ -60,7 +60,7 @@ branch in the publicly accessible GCC development tree.)</p>
</ul>
<p>There is no firm guideline for what constitutes a "major change"
-and what does not. If a developer is unsure, he or she should ask for
+and what does not. If a developer is unsure, they should ask for
guidance on the GCC mailing lists. In general, a change that has the
potential to be extremely destabilizing should be done on a branch.</p>
@@ -117,11 +117,11 @@ changes.</li>
<li>Approval should be necessary for
patches which don't fall under the obvious rule. So, with the approver list
put in place, everybody (except maintainers) should still seek approval for
-his/her patches. We have found the mutual peer review process really
+their patches. We have found the mutual peer review process really
works well.</li>
<li>Patches should only be reviewed by
people who know the affected parts of the compiler. (i.e. the
-reviewer has to be sure he/she knows stuff well enough to make a
+reviewer has to be sure they know stuff well enough to make a
good judgment.)</li>
<li>Large/complicated patches should
still go by one of our maintainers, or team consensus.</li>
@@ -37,7 +37,7 @@ is not sufficient).</p>
<p>If you already have an account on sourceware.org / gcc.gnu.org, ask
<code>overseers@gcc.gnu.org</code> to add access to the GCC repository.
-Include the name of your sponsor and CC: her.
+Include the name of your sponsor and CC: them.
Otherwise use <a
href="https://sourceware.org/cgi-bin/pdw/ps_form.cgi">this form</a>,
again specifying your sponsor.</p>
--
2.31.1