Rewrote some references to "master".

Following d9a266d657.

docs/conf.py

@@ -94,8 +94,8 @@ source_suffix = ".txt"
 # The encoding of source files.
 # source_encoding = 'utf-8-sig'
 
-# The master toctree document.
-master_doc = "contents"
+# The root document.
+root_doc = "contents"
 
 # General substitutions.
 project = "Django"
@@ -347,7 +347,7 @@ man_pages = [
 # description, category, toctree_only)
 texinfo_documents = [
     (
-        master_doc,
+        root_doc,
         "django",
         "",
         "",

docs/man/django-admin.1

@@ -870,9 +870,9 @@ If you\(aqre in a multi\-database setup, you might have fixture data that
 you want to load onto one database, but not onto another. In this
 situation, you can add a database identifier into the names of your fixtures.
 .sp
-For example, if your \fBDATABASES\fP setting has a \(aqmaster\(aq database
-defined, name the fixture \fBmydata.master.json\fP or
-\fBmydata.master.json.gz\fP and the fixture will only be loaded when you
+For example, if your \fBDATABASES\fP setting has a \(aqusers\(aq database
+defined, name the fixture \fBmydata.users.json\fP or
+\fBmydata.users.json.gz\fP and the fixture will only be loaded when you
 specify you want to load data into the \fBmaster\fP database.
 .SS Loading fixtures from \fBstdin\fP
 .sp
@@ -1815,7 +1815,7 @@ zip files, you can use a URL like:
 .sp
 .nf
 .ft C
-django\-admin startapp \-\-template=https://github.com/githubuser/django\-app\-template/archive/master.zip myapp
+django\-admin startapp \-\-template=https://github.com/githubuser/django\-app\-template/archive/main.zip myapp
 .ft P
 .fi
 .UNINDENT

docs/ref/class-based-views/base.txt

@@ -18,9 +18,9 @@ MRO is an acronym for Method Resolution Order.
 
 .. class:: django.views.generic.base.View
 
-    The master class-based base view. All other class-based views inherit from
-    this base class. It isn't strictly a generic view and thus can also be
-    imported from ``django.views``.
+    The base view class. All other class-based views inherit from this base
+    class. It isn't strictly a generic view and thus can also be imported from
+    ``django.views``.
 
     **Method Flowchart**
 

docs/ref/django-admin.txt

@@ -632,10 +632,10 @@ If you're in a multi-database setup, you might have fixture data that
 you want to load onto one database, but not onto another. In this
 situation, you can add a database identifier into the names of your fixtures.
 
-For example, if your :setting:`DATABASES` setting has a 'master' database
-defined, name the fixture ``mydata.master.json`` or
-``mydata.master.json.gz`` and the fixture will only be loaded when you
-specify you want to load data into the ``master`` database.
+For example, if your :setting:`DATABASES` setting has a 'users' database
+defined, name the fixture ``mydata.users.json`` or
+``mydata.users.json.gz`` and the fixture will only be loaded when you
+specify you want to load data into the ``users`` database.
 
 .. _loading-fixtures-stdin:
 
@@ -1311,7 +1311,7 @@ fly.
 For example, taking advantage of GitHub's feature to expose repositories as
 zip files, you can use a URL like::
 
-    django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
+    django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp
 
 .. django-admin-option:: --extension EXTENSIONS, -e EXTENSIONS
 

docs/requirements.txt

@@ -1,3 +1,3 @@
 pyenchant
-Sphinx>=3.1.0
+Sphinx>=4.0.0
 sphinxcontrib-spelling

docs/topics/db/multi-db.txt

@@ -233,18 +233,18 @@ Using routers
 
 Database routers are installed using the :setting:`DATABASE_ROUTERS`
 setting. This setting defines a list of class names, each specifying a
-router that should be used by the master router
+router that should be used by the base router
 (``django.db.router``).
 
-The master router is used by Django's database operations to allocate
+The base router is used by Django's database operations to allocate
 database usage. Whenever a query needs to know which database to use,
-it calls the master router, providing a model and a hint (if
-available). Django then tries each router in turn until a database
-suggestion can be found. If no suggestion can be found, it tries the
-current :attr:`instance._state.db <django.db.models.Model._state>` of the hint
-instance. If a hint instance wasn't provided, or :attr:`instance._state.db
-<django.db.models.Model._state>` is ``None``, the master router will allocate
-the ``default`` database.
+it calls the base router, providing a model and a hint (if
+available). The base router tries each router class in turn until one returns
+a database suggestion. If no routers return a suggestion, the base router tries
+the current :attr:`instance._state.db
+<django.db.models.Model._state>` of the hint instance. If no hint instance
+was provided, or :attr:`instance._state.db <django.db.models.Model._state>` is
+``None``, the base router will allocate the ``default`` database.
 
 An example
 ----------