[PATCH] docs: process: use gender-neutral pronouns

[PATCH] docs: process: use gender-neutral pronouns

[Ruben Sutton]

Several process documents use gendered pronouns when referring
generically to developers and maintainers. Use singular they instead,
making the language inclusive without changing its meaning.

Leave pronouns referring to named people and text in attributed
quotations unchanged.

Assisted-by: LLM
Signed-off-by: Ruben Sutton <ruben@scstudios.tech>
---
 Documentation/process/2.Process.rst            | 2 +-
 Documentation/process/5.Posting.rst            | 2 +-
 Documentation/process/6.Followthrough.rst      | 2 +-
 Documentation/process/handling-regressions.rst | 2 +-
 Documentation/process/howto.rst                | 2 +-
 Documentation/process/submitting-patches.rst   | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index 77f3f80e7c..75b5c236d8 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -227,7 +227,7 @@ tree, usually (but certainly not always) using the git source management
 tool.  Tools like git (and related tools like quilt or mercurial) allow
 maintainers to track a list of patches, including authorship information
 and other metadata.  At any given time, the maintainer can identify which
-patches in his or her repository are not found in the mainline.
+patches in their repository are not found in the mainline.
 
 When the merge window opens, top-level maintainers will ask Linus to "pull"
 the patches they have selected for merging from their repositories.  If
diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
index 07d7dbed13..6e61204403 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -233,7 +233,7 @@ the patch. Each of these uses this format::
 
 The tags in common use are:
 
- - Signed-off-by: this is a developer's certification that he or she has
+ - Signed-off-by: this is a developer's certification that they have
    the right to submit the patch for inclusion into the kernel.  It is an
    agreement to the Developer's Certificate of Origin, the full text of
    which can be found in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst
index 66fa400c6d..ebb0e4cc95 100644
--- a/Documentation/process/6.Followthrough.rst
+++ b/Documentation/process/6.Followthrough.rst
@@ -114,7 +114,7 @@ What happens next
 If a patch is considered to be a good thing to add to the kernel, and once
 most of the review issues have been resolved, the next step is usually
 entry into a subsystem maintainer's tree.  How that works varies from one
-subsystem to the next; each maintainer has his or her own way of doing
+subsystem to the next; each maintainer has their own way of doing
 things.  In particular, there may be more than one tree - one, perhaps,
 dedicated to patches planned for the next merge window, and another for
 longer-term work.
diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst
index c71b5d403f..6958a2a8b0 100644
--- a/Documentation/process/handling-regressions.rst
+++ b/Documentation/process/handling-regressions.rst
@@ -283,7 +283,7 @@ sure your patch description makes this aspect obvious. Once the change is
 merged, tell the Linux kernel's regression tracker and the regressions mailing
 list about the risk, so everyone has the change on the radar in case reports
 trickle in. Depending on the risk, you also might want to ask the subsystem
-maintainer to mention the issue in his mainline pull request.
+maintainer to mention the issue in their mainline pull request.
 
 What else is there to known about regressions?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 9438e03d6f..8c60138d03 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -305,7 +305,7 @@ The maintainers of the various kernel subsystems --- and also many
 kernel subsystem developers --- expose their current state of
 development in source repositories.  That way, others can see what is
 happening in the different areas of the kernel.  In areas where
-development is rapid, a developer may be asked to base his submissions
+development is rapid, a developer may be asked to base their submissions
 onto such a subsystem kernel tree so that conflicts between the
 submission and other already ongoing work are avoided.
 
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 7ae79452e1..4c28a239e8 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -456,7 +456,7 @@ When to use Acked-by:, Cc:, and Co-developed-by:
 ------------------------------------------------
 
 The Signed-off-by: tag indicates that the signer was involved in the
-development of the patch, or that he/she was in the patch's delivery path.
+development of the patch, or that they were in the patch's delivery path.
 
 If a person was not directly involved in the preparation or handling of a
 patch but wishes to signify and record their approval of it then they can

base-commit: 893e11787f78e43b534e252249ac3fff4d1333f8
-- 
2.54.0 (Apple Git-157)

Re: [PATCH] docs: process: use gender-neutral pronouns

[Jonathan Corbet]

Ruben Sutton <ruben@scstudios.tech> writes:

> Several process documents use gendered pronouns when referring
> generically to developers and maintainers. Use singular they instead,
> making the language inclusive without changing its meaning.
>
> Leave pronouns referring to named people and text in attributed
> quotations unchanged.
>
> Assisted-by: LLM
> Signed-off-by: Ruben Sutton <ruben@scstudios.tech>
> ---
>  Documentation/process/2.Process.rst            | 2 +-
>  Documentation/process/5.Posting.rst            | 2 +-
>  Documentation/process/6.Followthrough.rst      | 2 +-
>  Documentation/process/handling-regressions.rst | 2 +-
>  Documentation/process/howto.rst                | 2 +-
>  Documentation/process/submitting-patches.rst   | 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)

Ouch.

I have no objection in principle to this change, but if we try to clean
up the whole kernel in this way we're going to have a *lot* of churn
and, undoubtedly, some unpleasant discussions at some point.

I'm tempted to raise this question at the maintainers summit to see if I
can get some sort of project-wide policy laid out.

Thanks,

jon

Re: [PATCH] docs: process: use gender-neutral pronouns

[Kees Cook]

On Wed, Sep 09, 2026 at 09:14:04AM -0600, Jonathan Corbet wrote:
> Ruben Sutton <ruben@scstudios.tech> writes:
> 
> > Several process documents use gendered pronouns when referring
> > generically to developers and maintainers. Use singular they instead,
> > making the language inclusive without changing its meaning.
> >
> > Leave pronouns referring to named people and text in attributed
> > quotations unchanged.
> >
> > Assisted-by: LLM
> > Signed-off-by: Ruben Sutton <ruben@scstudios.tech>
> > ---
> >  Documentation/process/2.Process.rst            | 2 +-
> >  Documentation/process/5.Posting.rst            | 2 +-
> >  Documentation/process/6.Followthrough.rst      | 2 +-
> >  Documentation/process/handling-regressions.rst | 2 +-
> >  Documentation/process/howto.rst                | 2 +-
> >  Documentation/process/submitting-patches.rst   | 2 +-
> >  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> Ouch.
> 
> I have no objection in principle to this change, but if we try to clean
> up the whole kernel in this way we're going to have a *lot* of churn
> and, undoubtedly, some unpleasant discussions at some point.
> 
> I'm tempted to raise this question at the maintainers summit to see if I
> can get some sort of project-wide policy laid out.

FWIW, I'd agree "indefinite they" (or "singular they") is the right
language here: "his or her" is both annoying to read (too many words)
and non-inclusive. Using "their" solves both.

-Kees

-- 
Kees Cook

Re: [PATCH] docs: process: use gender-neutral pronouns

[Thorsten Leemhuis]

On 9/9/26 20:47, Kees Cook wrote:
> On Wed, Sep 09, 2026 at 09:14:04AM -0600, Jonathan Corbet wrote:
>> Ruben Sutton <ruben@scstudios.tech> writes:
>>
>>> Several process documents use gendered pronouns when referring
>>> generically to developers and maintainers. Use singular they instead,
>>> making the language inclusive without changing its meaning.
>>>
>>> Leave pronouns referring to named people and text in attributed
>>> quotations unchanged.
>>
>> Ouch.
>>
>> I have no objection in principle to this change, but if we try to clean
>> up the whole kernel in this way we're going to have a *lot* of churn
>> and, undoubtedly, some unpleasant discussions at some point.
>>
>> I'm tempted to raise this question at the maintainers summit to see if I
>> can get some sort of project-wide policy laid out.
> 
> FWIW, I'd agree "indefinite they" (or "singular they") is the right
> language here: "his or her" is both annoying to read (too many words)
> and non-inclusive. Using "their" solves both.
I do, too.

But all this makes me wonder: In case we decide to go down that route,
how do we prevent gendered pronouns from accidentally sneaking back in,
for example, through subsystems that change their docs directly? Do we
maybe have something already somewhere that watches changes to
Documentation/ where we could plug in a test script that yells if it
detects this in next? And yes, obviously someone would then also need to
write such a script.

Ciao, Thorsten

Re: [PATCH] docs: process: use gender-neutral pronouns

[Laurent Pinchart]

On Thu, Sep 10, 2026 at 08:59:04AM +0200, Thorsten Leemhuis wrote:
> On 9/9/26 20:47, Kees Cook wrote:
> > On Wed, Sep 09, 2026 at 09:14:04AM -0600, Jonathan Corbet wrote:
> >> Ruben Sutton writes:
> >>
> >>> Several process documents use gendered pronouns when referring
> >>> generically to developers and maintainers. Use singular they instead,
> >>> making the language inclusive without changing its meaning.
> >>>
> >>> Leave pronouns referring to named people and text in attributed
> >>> quotations unchanged.
> >>
> >> Ouch.
> >>
> >> I have no objection in principle to this change, but if we try to clean
> >> up the whole kernel in this way we're going to have a *lot* of churn
> >> and, undoubtedly, some unpleasant discussions at some point.
> >>
> >> I'm tempted to raise this question at the maintainers summit to see if I
> >> can get some sort of project-wide policy laid out.
> > 
> > FWIW, I'd agree "indefinite they" (or "singular they") is the right
> > language here: "his or her" is both annoying to read (too many words)
> > and non-inclusive. Using "their" solves both.
> I do, too.
> 
> But all this makes me wonder: In case we decide to go down that route,
> how do we prevent gendered pronouns from accidentally sneaking back in,
> for example, through subsystems that change their docs directly? Do we
> maybe have something already somewhere that watches changes to
> Documentation/ where we could plug in a test script that yells if it
> detects this in next? And yes, obviously someone would then also need to
> write such a script.

This appears to me as similar to the words we decided to ban in commit
a5f526ecb075 ("CodingStyle: Inclusive Terminology"). As far as I'm
aware, there's no tooling to enforce this, we instead rely on reviewers
(and authors in the first place of course) knowing the rules. The
inclusive terminology discussion that occurred back then made the news,
helping us to raise awareness of the rules. For gender-neutral pronouns
we may need to communicate a bit more proactively towards at least
subsystem maintainers.

-- 
Regards,

Laurent Pinchart