Refs #31676 -- Used term "merger" instead of "committer" in docs.

Follow up to caa2dd08c4722c8702588f5dfe1fa4c506aa66fc.

Co-authored-by: Carlton Gibson <carlton.gibson@noumenal.es>

1 files changed, 11 insertions, 12 deletions

diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt
index 35a3ad13ce..ed94ee9609 100644
--- a/docs/internals/contributing/committing-code.txt
+++ b/docs/internals/contributing/committing-code.txt
@@ -2,7 +2,7 @@
 Committing code
 ===============
 
-This section is addressed to the committers and to anyone interested in knowing
+This section is addressed to the mergers and to anyone interested in knowing
 how code gets committed into Django. If you're a community member who wants to
 contribute code to Django, look at :doc:`writing-code/working-with-git` instead.
 
@@ -16,9 +16,9 @@ requests.
 
 When committing a pull request, make sure each individual commit matches the
 commit guidelines described below. Contributors are expected to provide the
-best pull requests possible. In practice however, committers - who will likely
-be more familiar with the commit guidelines - may decide to bring a commit up
-to standard themselves.
+best pull requests possible. In practice however, mergers - who will likely be
+more familiar with the commit guidelines - may decide to bring a commit up to
+standard themselves.
 
 You may want to have Jenkins or GitHub actions test the pull request with one
 of the pull request builders that doesn't run automatically, such as Oracle or
@@ -90,7 +90,7 @@ Django's commit history as usable as possible:
 * Trivial and small patches usually are best done in one commit. Medium to
   large work may be split into multiple commits if it makes sense.
 
-Practicality beats purity, so it is up to each committer to decide how much
+Practicality beats purity, so it is up to each merger to decide how much
 history mangling to do for a pull request. The main points are engaging the
 community, getting work done, and having a usable commit history.
 
@@ -192,8 +192,8 @@ Django's Git repository:
     Backport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from main.
 
   There's a `script on the wiki
-  <https://code.djangoproject.com/wiki/CommitterTips#AutomatingBackports>`_
-  to automate this.
+  <https://code.djangoproject.com/wiki/MergerTips#AutomatingBackports>`_ to
+  automate this.
 
   If the commit fixes a regression, include this in the commit message:
 
@@ -211,7 +211,7 @@ Nobody's perfect; mistakes will be committed.
 But try very hard to ensure that mistakes don't happen. Just because we have a
 reversion policy doesn't relax your responsibility to aim for the highest
 quality possible. Really: double-check your work, or have it checked by
-another committer, **before** you commit it in the first place!
+another merger, **before** you commit it in the first place!
 
 When a mistaken commit is discovered, please follow these guidelines:
 
@@ -231,10 +231,9 @@ When a mistaken commit is discovered, please follow these guidelines:
 * If the problem is small (a feature commit after feature freeze,
   say), wait it out.
 
-* If there's a disagreement between the committer and the
-  reverter-to-be then try to work it out on the |django-developers|
-  mailing list. If an agreement can't be reached then it should
-  be put to a vote.
+* If there's a disagreement between the merger and the reverter-to-be then try
+  to work it out on the |django-developers| mailing list. If an agreement can't
+  be reached then it should be put to a vote.
 
 * If the commit introduced a confirmed, disclosed security
   vulnerability then the commit may be reverted immediately without