Refs #36485 -- Removed unnecessary parentheses in :meth: and :func: roles in docs.

6 files changed, 72 insertions, 72 deletions

diff --git a/docs/ref/models/expressions.txt b/docs/ref/models/expressions.txt
index 9e0eb3ba65..0d0e82df13 100644
--- a/docs/ref/models/expressions.txt
+++ b/docs/ref/models/expressions.txt
@@ -166,12 +166,12 @@ To access the new value saved this way, the object must be reloaded::
 As well as being used in operations on single instances as above, ``F()`` can
 be used with ``update()`` to perform bulk updates on a ``QuerySet``. This
 reduces the two queries we were using above - the ``get()`` and the
-:meth:`~Model.save()` - to just one::
+:meth:`~Model.save` - to just one::
 
     reporter = Reporters.objects.filter(name="Tintin")
     reporter.update(stories_filed=F("stories_filed") + 1)
 
-We can also use :meth:`~django.db.models.query.QuerySet.update()` to increment
+We can also use :meth:`~django.db.models.query.QuerySet.update` to increment
 the field value on multiple objects - which could be very much faster than
 pulling them all into Python from the database, looping over them, incrementing
 the field value of each one, and saving each one back to the database::
@@ -218,14 +218,14 @@ based on the original value; the work of the first thread will be lost.
 
 If the database is responsible for updating the field, the process is more
 robust: it will only ever update the field based on the value of the field in
-the database when the :meth:`~Model.save()` or ``update()`` is executed, rather
+the database when the :meth:`~Model.save` or ``update()`` is executed, rather
 than based on its value when the instance was retrieved.
 
 ``F()`` assignments persist after ``Model.save()``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 ``F()`` objects assigned to model fields persist after saving the model
-instance and will be applied on each :meth:`~Model.save()`. For example::
+instance and will be applied on each :meth:`~Model.save`. For example::
 
     reporter = Reporters.objects.get(name="Tintin")
     reporter.stories_filed = F("stories_filed") + 1
@@ -237,7 +237,7 @@ instance and will be applied on each :meth:`~Model.save()`. For example::
 ``stories_filed`` will be updated twice in this case. If it's initially ``1``,
 the final value will be ``3``. This persistence can be avoided by reloading the
 model object after saving it, for example, by using
-:meth:`~Model.refresh_from_db()`.
+:meth:`~Model.refresh_from_db`.
 
 Using ``F()`` in filters
 ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1199,7 +1199,7 @@ calling the appropriate methods on the wrapped expression.
         implementing ``NULLS LAST`` would change its value to be
         ``NULLS FIRST``. Modifications are only required for expressions that
         implement sort order like ``OrderBy``. This method is called when
-        :meth:`~django.db.models.query.QuerySet.reverse()` is called on a
+        :meth:`~django.db.models.query.QuerySet.reverse` is called on a
         queryset.
 
 .. _writing-your-own-query-expressions:
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 372f86657f..430efcd446 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -292,7 +292,7 @@ modifications:
 
     These property names cannot be used as member names as they would conflict.
 
-* The use of :func:`enum.unique()` is enforced to ensure that values cannot be
+* The use of :func:`enum.unique` is enforced to ensure that values cannot be
   defined multiple times. This is unlikely to be expected in choices for a
   field.
 
@@ -603,11 +603,11 @@ portion of the field will be considered. Besides, when :setting:`USE_TZ` is
 ``True``, the check will be performed in the :ref:`current time zone
 <default-current-time-zone>` at the time the object gets saved.
 
-This is enforced by :meth:`Model.validate_unique()` during model validation
+This is enforced by :meth:`Model.validate_unique` during model validation
 but not at the database level. If any :attr:`~Field.unique_for_date` constraint
 involves fields that are not part of a :class:`~django.forms.ModelForm` (for
 example, if one of the fields is listed in ``exclude`` or has
-:attr:`editable=False<Field.editable>`), :meth:`Model.validate_unique()` will
+:attr:`editable=False<Field.editable>`), :meth:`Model.validate_unique` will
 skip validation for that particular constraint.
 
 ``unique_for_month``
@@ -1316,8 +1316,8 @@ materialized view.
 .. admonition:: Refresh the data
 
     Since the database computes the value, the object must be reloaded to
-    access the new value after :meth:`~Model.save()`, for example, by using
-    :meth:`~Model.refresh_from_db()`.
+    access the new value after :meth:`~Model.save`, for example, by using
+    :meth:`~Model.refresh_from_db`.
 
 .. admonition:: Database limitations
 
@@ -1796,7 +1796,7 @@ The possible values for :attr:`~ForeignKey.on_delete` are found in
 * .. function:: SET()
 
     Set the :class:`ForeignKey` to the value passed to
-    :func:`~django.db.models.SET()`, or if a callable is passed in,
+    :func:`~django.db.models.SET`, or if a callable is passed in,
     the result of calling it. In most cases, passing a callable will be
     necessary to avoid executing queries at the time your ``models.py`` is
     imported::
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index da440f1ba9..6baa0cb27d 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -23,7 +23,7 @@ class:
 
 The keyword arguments are the names of the fields you've defined on your model.
 Note that instantiating a model in no way touches your database; for that, you
-need to :meth:`~Model.save()`.
+need to :meth:`~Model.save`.
 
 .. note::
 
@@ -226,27 +226,27 @@ Validating objects
 
 There are four steps involved in validating a model:
 
-1. Validate the model fields - :meth:`Model.clean_fields()`
-2. Validate the model as a whole - :meth:`Model.clean()`
-3. Validate the field uniqueness - :meth:`Model.validate_unique()`
+1. Validate the model fields - :meth:`Model.clean_fields`
+2. Validate the model as a whole - :meth:`Model.clean`
+3. Validate the field uniqueness - :meth:`Model.validate_unique`
 4. Validate the constraints - :meth:`Model.validate_constraints`
 
 All four steps are performed when you call a model's :meth:`~Model.full_clean`
 method.
 
 When you use a :class:`~django.forms.ModelForm`, the call to
-:meth:`~django.forms.Form.is_valid()` will perform these validation steps for
+:meth:`~django.forms.Form.is_valid` will perform these validation steps for
 all the fields that are included on the form. See the :doc:`ModelForm
 documentation </topics/forms/modelforms>` for more information. You should only
-need to call a model's :meth:`~Model.full_clean()` method if you plan to handle
+need to call a model's :meth:`~Model.full_clean` method if you plan to handle
 validation errors yourself, or if you have excluded fields from the
 :class:`~django.forms.ModelForm` that require validation.
 
 .. method:: Model.full_clean(exclude=None, validate_unique=True, validate_constraints=True)
 
-This method calls :meth:`Model.clean_fields()`, :meth:`Model.clean()`,
-:meth:`Model.validate_unique()` (if ``validate_unique`` is ``True``),  and
-:meth:`Model.validate_constraints()` (if ``validate_constraints`` is ``True``)
+This method calls :meth:`Model.clean_fields`, :meth:`Model.clean`,
+:meth:`Model.validate_unique` (if ``validate_unique`` is ``True``),  and
+:meth:`Model.validate_constraints` (if ``validate_constraints`` is ``True``)
 in that order and raises a :exc:`~django.core.exceptions.ValidationError` that
 has a ``message_dict`` attribute containing errors from all four stages.
 
@@ -257,7 +257,7 @@ aren't present on your form from being validated since any errors raised could
 not be corrected by the user.
 
 Note that ``full_clean()`` will *not* be called automatically when you call
-your model's :meth:`~Model.save()` method. You'll need to call it manually
+your model's :meth:`~Model.save` method. You'll need to call it manually
 when you want to run one-step model validation for your own manually created
 models. For example::
 
@@ -279,7 +279,7 @@ argument lets you provide a ``set`` of field names to exclude from validation.
 It will raise a :exc:`~django.core.exceptions.ValidationError` if any fields
 fail validation.
 
-The second step ``full_clean()`` performs is to call :meth:`Model.clean()`.
+The second step ``full_clean()`` performs is to call :meth:`Model.clean`.
 This method should be overridden to perform custom validation on your model.
 
 .. method:: Model.clean()
@@ -306,8 +306,8 @@ access to more than a single field::
             if self.status == "published" and self.pub_date is None:
                 self.pub_date = datetime.date.today()
 
-Note, however, that like :meth:`Model.full_clean()`, a model's ``clean()``
-method is not invoked when you call your model's :meth:`~Model.save()` method.
+Note, however, that like :meth:`Model.full_clean`, a model's ``clean()``
+method is not invoked when you call your model's :meth:`~Model.save` method.
 
 In the above example, the :exc:`~django.core.exceptions.ValidationError`
 exception raised by ``Model.clean()`` was instantiated with a string, so it
@@ -582,10 +582,10 @@ Forcing an INSERT or UPDATE
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In some rare circumstances, it's necessary to be able to force the
-:meth:`~Model.save()` method to perform an SQL ``INSERT`` and not fall back to
+:meth:`~Model.save` method to perform an SQL ``INSERT`` and not fall back to
 doing an ``UPDATE``. Or vice-versa: update, if possible, but not insert a new
 row. In these cases you can pass the ``force_insert=True`` or
-``force_update=True`` parameters to the :meth:`~Model.save()` method.
+``force_update=True`` parameters to the :meth:`~Model.save` method.
 Passing both parameters is an error: you cannot both insert *and* update at the
 same time!
 
@@ -672,8 +672,8 @@ perform an update on all fields.
 Specifying ``update_fields`` will force an update.
 
 When saving a model fetched through deferred model loading
-(:meth:`~django.db.models.query.QuerySet.only()` or
-:meth:`~django.db.models.query.QuerySet.defer()`) only the fields loaded
+(:meth:`~django.db.models.query.QuerySet.only` or
+:meth:`~django.db.models.query.QuerySet.defer`) only the fields loaded
 from the DB will get updated. In effect there is an automatic
 ``update_fields`` in this case. If you assign or change any deferred field
 value, the field will be added to the updated fields.
@@ -894,7 +894,7 @@ track down every place that the URL might be created. Specify it once, in
 Extra instance methods
 ======================
 
-In addition to :meth:`~Model.save()`, :meth:`~Model.delete()`, a model object
+In addition to :meth:`~Model.save`, :meth:`~Model.delete`, a model object
 might have some of the following methods:
 
 .. method:: Model.get_FOO_display()
diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt
index 30fa3cc374..fce426ac97 100644
--- a/docs/ref/models/options.txt
+++ b/docs/ref/models/options.txt
@@ -382,7 +382,7 @@ not be looking at your Django code. For example::
 .. attribute:: Options.select_on_save
 
     Determines if Django will use the pre-1.6
-    :meth:`django.db.models.Model.save()` algorithm. The old algorithm
+    :meth:`django.db.models.Model.save` algorithm. The old algorithm
     uses ``SELECT`` to determine if there is an existing row to be updated.
     The new algorithm tries an ``UPDATE`` directly. In some rare cases the
     ``UPDATE`` of an existing row isn't visible to Django. An example is the
@@ -393,7 +393,7 @@ not be looking at your Django code. For example::
     Usually there is no need to set this attribute. The default is
     ``False``.
 
-    See :meth:`django.db.models.Model.save()` for more about the old and
+    See :meth:`django.db.models.Model.save` for more about the old and
     new saving algorithm.
 
 ``indexes``
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index ef6ceb36ad..fc568422b6 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -166,7 +166,7 @@ Here's the formal declaration of a ``QuerySet``:
     .. attribute:: ordered
 
         ``True`` if the ``QuerySet`` is ordered — i.e. has an
-        :meth:`order_by()` clause or a default ordering on the model.
+        :meth:`order_by` clause or a default ordering on the model.
         ``False`` otherwise.
 
     .. attribute:: db
@@ -401,7 +401,7 @@ expression::
 (``nulls_first`` and ``nulls_last``) that control how null values are sorted.
 
 Be cautious when ordering by fields in related models if you are also using
-:meth:`distinct()`. See the note in :meth:`distinct` for an explanation of how
+:meth:`distinct`. See the note in :meth:`distinct` for an explanation of how
 related model ordering can change the expected results.
 
 .. note::
@@ -445,7 +445,7 @@ ordering::
     Entry.objects.order_by(Lower("headline").desc())
 
 If you don't want any ordering to be applied to a query, not even the default
-ordering, call :meth:`order_by()` with no parameters.
+ordering, call :meth:`order_by` with no parameters.
 
 You can tell if a query is ordered or not by checking the
 :attr:`.QuerySet.ordered` attribute, which will be ``True`` if the
@@ -490,7 +490,7 @@ efficiently in SQL.
 
 Also, note that ``reverse()`` should generally only be called on a ``QuerySet``
 which has a defined ordering (e.g., when querying against a model which defines
-a default ordering, or when using :meth:`order_by()`). If no such ordering is
+a default ordering, or when using :meth:`order_by`). If no such ordering is
 defined for a given ``QuerySet``, calling ``reverse()`` on it has no real
 effect (the ordering was undefined prior to calling ``reverse()``, and will
 remain undefined afterward).
@@ -518,14 +518,14 @@ query spans multiple tables, it's possible to get duplicate results when a
     don't appear in the returned results (they are only there to support
     ordering), it sometimes looks like non-distinct results are being returned.
 
-    Similarly, if you use a :meth:`values()` query to restrict the columns
-    selected, the columns used in any :meth:`order_by()` (or default model
+    Similarly, if you use a :meth:`values` query to restrict the columns
+    selected, the columns used in any :meth:`order_by` (or default model
     ordering) will still be involved and may affect uniqueness of the results.
 
     The moral here is that if you are using ``distinct()`` be careful about
     ordering by related models. Similarly, when using ``distinct()`` and
-    :meth:`values()` together, be careful when ordering by fields not in the
-    :meth:`values()` call.
+    :meth:`values` together, be careful when ordering by fields not in the
+    :meth:`values` call.
 
 On PostgreSQL only, you can pass positional arguments (``*fields``) in order to
 specify the names of fields to which the ``DISTINCT`` should apply. This
@@ -675,17 +675,17 @@ A few subtleties that are worth mentioning:
     >>> Entry.objects.values("blog_id")
     <QuerySet [{'blog_id': 1}, ...]>
 
-* When using ``values()`` together with :meth:`distinct()`, be aware that
+* When using ``values()`` together with :meth:`distinct`, be aware that
   ordering can affect the results. See the note in :meth:`distinct` for
   details.
 
-* If you use a ``values()`` clause after an :meth:`extra()` call,
-  any fields defined by a ``select`` argument in the :meth:`extra()` must
-  be explicitly included in the ``values()`` call. Any :meth:`extra()` call
+* If you use a ``values()`` clause after an :meth:`extra` call,
+  any fields defined by a ``select`` argument in the :meth:`extra` must
+  be explicitly included in the ``values()`` call. Any :meth:`extra` call
   made after a ``values()`` call will have its extra selected fields
   ignored.
 
-* Calling :meth:`only()` and :meth:`defer()` after ``values()`` doesn't make
+* Calling :meth:`only` and :meth:`defer` after ``values()`` doesn't make
   sense, so doing so will raise a ``TypeError``.
 
 * Combining transforms and aggregates requires the use of two :meth:`annotate`
@@ -998,7 +998,7 @@ resulting ``QuerySet``. For example:
 
 In addition, only ``LIMIT``, ``OFFSET``, ``COUNT(*)``, ``ORDER BY``, and
 specifying columns (i.e. slicing, :meth:`count`, :meth:`exists`,
-:meth:`order_by`, and :meth:`values()`/:meth:`values_list()`) are allowed
+:meth:`order_by`, and :meth:`values`/:meth:`values_list`) are allowed
 on the resulting ``QuerySet``. Further, databases place restrictions on
 what operations are allowed in the combined queries. For example, most
 databases don't allow ``LIMIT`` or ``OFFSET`` in the combined queries.
@@ -1363,7 +1363,7 @@ This can be used to change the default ordering of the queryset:
     ...     Prefetch("pizzas__toppings", queryset=Toppings.objects.order_by("name"))
     ... )
 
-Or to call :meth:`~django.db.models.query.QuerySet.select_related()` when
+Or to call :meth:`~django.db.models.query.QuerySet.select_related` when
 applicable to reduce the number of queries even further:
 
 .. code-block:: pycon
@@ -1418,7 +1418,7 @@ less ambiguous than storing a filtered result in the related manager's cache:
 
 Custom prefetching also works with single related relations like
 forward ``ForeignKey`` or ``OneToOneField``. Generally you'll want to use
-:meth:`select_related()` for these relations, but there are a number of cases
+:meth:`select_related` for these relations, but there are a number of cases
 where prefetching with a custom ``QuerySet`` is useful:
 
 * You want to use a ``QuerySet`` that performs further prefetching
@@ -1665,7 +1665,7 @@ of the arguments is required, but you should use at least one of them.
   fields or tables you have included via ``extra()`` use the ``order_by``
   parameter to ``extra()`` and pass in a sequence of strings. These
   strings should either be model fields (as in the normal
-  :meth:`order_by()` method on querysets), of the form
+  :meth:`order_by` method on querysets), of the form
   ``table_name.column_name`` or an alias for a column that you specified
   in the ``select`` parameter to ``extra()``.
 
@@ -1753,7 +1753,7 @@ Calling ``defer()`` with a field name that has already been deferred is
 harmless (the field will still be deferred).
 
 You can defer loading of fields in related models (if the related models are
-loading via :meth:`select_related()`) by using the standard double-underscore
+loading via :meth:`select_related`) by using the standard double-underscore
 notation to separate related fields::
 
     Blog.objects.select_related().defer("entry__headline", "entry__body")
@@ -1766,18 +1766,18 @@ to ``defer()``::
 
 Some fields in a model won't be deferred, even if you ask for them. You can
 never defer the loading of the primary key. If you are using
-:meth:`select_related()` to retrieve related models, you shouldn't defer the
+:meth:`select_related` to retrieve related models, you shouldn't defer the
 loading of the field that connects from the primary model to the related
 one, doing so will result in an error.
 
-Similarly, calling ``defer()`` (or its counterpart :meth:`only()`) including an
-argument from an aggregation (e.g. using the result of :meth:`annotate()`)
+Similarly, calling ``defer()`` (or its counterpart :meth:`only`) including an
+argument from an aggregation (e.g. using the result of :meth:`annotate`)
 doesn't make sense: doing so will raise an exception. The aggregated values
 will always be fetched into the resulting queryset.
 
 .. note::
 
-    The ``defer()`` method (and its cousin, :meth:`only()`, below) are only for
+    The ``defer()`` method (and its cousin, :meth:`only`, below) are only for
     advanced use-cases. They provide an optimization for when you have analyzed
     your queries closely and understand *exactly* what information you need and
     have measured that the difference between returning the fields you need and
@@ -1824,9 +1824,9 @@ will always be fetched into the resulting queryset.
 
 .. note::
 
-    When calling :meth:`~django.db.models.Model.save()` for instances with
+    When calling :meth:`~django.db.models.Model.save` for instances with
     deferred fields, only the loaded fields will be saved. See
-    :meth:`~django.db.models.Model.save()` for more details.
+    :meth:`~django.db.models.Model.save` for more details.
 
 ``only()``
 ~~~~~~~~~~
@@ -1880,9 +1880,9 @@ are in your ``only()`` call.
 
 .. note::
 
-    When calling :meth:`~django.db.models.Model.save()` for instances with
+    When calling :meth:`~django.db.models.Model.save` for instances with
     deferred fields, only the loaded fields will be saved. See
-    :meth:`~django.db.models.Model.save()` for more details.
+    :meth:`~django.db.models.Model.save` for more details.
 
 .. note::
 
@@ -2014,7 +2014,7 @@ raised if ``select_for_update()`` is used in autocommit mode.
     Although ``select_for_update()`` normally fails in autocommit mode, since
     :class:`~django.test.TestCase` automatically wraps each test in a
     transaction, calling ``select_for_update()`` in a ``TestCase`` even outside
-    an :func:`~django.db.transaction.atomic()` block will (perhaps unexpectedly)
+    an :func:`~django.db.transaction.atomic` block will (perhaps unexpectedly)
     pass without raising a ``TransactionManagementError``. To properly test
     ``select_for_update()`` you should use
     :class:`~django.test.TransactionTestCase`.
@@ -2245,7 +2245,7 @@ example can be rewritten using ``get_or_create()`` like so::
     )
 
 Any keyword arguments passed to ``get_or_create()`` — *except* an optional one
-called ``defaults`` — will be used in a :meth:`get()` call. If an object is
+called ``defaults`` — will be used in a :meth:`get` call. If an object is
 found, ``get_or_create()`` returns a tuple of that object and ``False``.
 
 .. warning::
@@ -2293,7 +2293,7 @@ If you have a field named ``defaults`` and want to use it as an exact lookup in
 
     Foo.objects.get_or_create(defaults__exact="bar", defaults={"defaults": "baz"})
 
-The ``get_or_create()`` method has similar error behavior to :meth:`create()`
+The ``get_or_create()`` method has similar error behavior to :meth:`create`
 when you're using manually specified primary keys. If an object needs to be
 created and the key already exists in the database, an
 :exc:`~django.db.IntegrityError` will be raised.
@@ -2712,7 +2712,7 @@ If your model's :ref:`Meta <meta-options>` specifies
 ``earliest()`` or ``latest()``. The fields specified in
 :attr:`~django.db.models.Options.get_latest_by` will be used by default.
 
-Like :meth:`get()`, ``earliest()`` and ``latest()`` raise
+Like :meth:`get`, ``earliest()`` and ``latest()`` raise
 :exc:`~django.db.models.Model.DoesNotExist` if there is no object with the
 given parameters.
 
@@ -2774,7 +2774,7 @@ equivalent to the above example::
 
 *Asynchronous version*: ``alast()``
 
-Works like  :meth:`first()`, but returns the last object in the queryset.
+Works like  :meth:`first`, but returns the last object in the queryset.
 
 ``aggregate()``
 ~~~~~~~~~~~~~~~
@@ -2975,8 +2975,8 @@ does not call any ``save()`` methods on your models, nor does it emit the
 :attr:`~django.db.models.signals.post_save` signals (which are a consequence of
 calling :meth:`Model.save() <django.db.models.Model.save>`). If you want to
 update a bunch of records for a model that has a custom
-:meth:`~django.db.models.Model.save()` method, loop over them and call
-:meth:`~django.db.models.Model.save()`, like this::
+:meth:`~django.db.models.Model.save` method, loop over them and call
+:meth:`~django.db.models.Model.save`, like this::
 
     for e in Entry.objects.filter(pub_date__year=2010):
         e.comments_on = False
@@ -3130,8 +3130,8 @@ there are triggers or if a function is called, even for a ``SELECT`` query.
 -----------------
 
 Field lookups are how you specify the meat of an SQL ``WHERE`` clause. They're
-specified as keyword arguments to the ``QuerySet`` methods :meth:`filter()`,
-:meth:`exclude()` and :meth:`get()`.
+specified as keyword arguments to the ``QuerySet`` methods :meth:`filter`,
+:meth:`exclude` and :meth:`get`.
 
 For an introduction, see :ref:`models and database queries documentation
 <field-lookups-intro>`.
@@ -4157,11 +4157,11 @@ such as ``|`` (``OR``), ``&`` (``AND``), and ``^`` (``XOR``). See
 .. class:: Prefetch(lookup, queryset=None, to_attr=None)
 
 The ``Prefetch()`` object can be used to control the operation of
-:meth:`~django.db.models.query.QuerySet.prefetch_related()`.
+:meth:`~django.db.models.query.QuerySet.prefetch_related`.
 
 The ``lookup`` argument describes the relations to follow and works the same
 as the string based lookups passed to
-:meth:`~django.db.models.query.QuerySet.prefetch_related()`. For example:
+:meth:`~django.db.models.query.QuerySet.prefetch_related`. For example:
 
 .. code-block:: pycon
 
@@ -4175,7 +4175,7 @@ as the string based lookups passed to
 
 The ``queryset`` argument supplies a base ``QuerySet`` for the given lookup.
 This is useful to further filter down the prefetch operation, or to call
-:meth:`~django.db.models.query.QuerySet.select_related()` from the prefetched
+:meth:`~django.db.models.query.QuerySet.select_related` from the prefetched
 relation, hence reducing the number of queries even further:
 
 .. code-block:: pycon
@@ -4243,7 +4243,7 @@ overridden by using a custom queryset in a related lookup.
 
         A :class:`~django.db.models.Q` object to control the filtering.
 
-``FilteredRelation`` is used with :meth:`~.QuerySet.annotate()` to create an
+``FilteredRelation`` is used with :meth:`~.QuerySet.annotate` to create an
 ``ON`` clause when a ``JOIN`` is performed. It doesn't act on the default
 relationship but on the annotation name (``pizzas_vegetarian`` in example
 below).
diff --git a/docs/ref/models/relations.txt b/docs/ref/models/relations.txt
index f941b435cc..2abe90c68c 100644
--- a/docs/ref/models/relations.txt
+++ b/docs/ref/models/relations.txt
@@ -132,7 +132,7 @@ Related objects reference
             >>> e = Entry.objects.get(id=234)
             >>> b.entry_set.remove(e)  # Disassociates Entry e from Blog b.
 
-        Similar to :meth:`add()`, ``e.save()`` is called in the example above
+        Similar to :meth:`add`, ``e.save()`` is called in the example above
         to perform the update. Using ``remove()`` with a many-to-many
         relationship, however, will delete the relationships using
         :meth:`QuerySet.delete()<django.db.models.query.QuerySet.delete>` which