doc: fix ~75 typos and grammar issues across documentation (#14179)

Fix typos, grammar errors, and broken RST directives found across 37 documentation files including how-to guides, reference docs, examples, explanations, and project root files.

Notable fixes:
- Broken RST directives (``.. note:`` → ``.. note::``)
- Subject-verb agreement errors
- Missing/incorrect articles and prepositions
- Incorrect verb forms ("teared down" → "torn down")
- Duplicate words and extra spaces
- Wrong URL in changelog (pytest → pytest-xdist)
- Ordinal typo ("3th" → "3rd")

(cherry picked from commit b2310f2)

Author: him2him2

CONTRIBUTING.rst

@@ -146,7 +146,7 @@ the following:
 - PyPI presence with packaging metadata that contains a ``pytest-``
   prefixed name, version number, authors, short and long description.
 
-- a  `tox configuration <https://tox.readthedocs.io/en/latest/config.html#configuration-discovery>`_
+- a `tox configuration <https://tox.readthedocs.io/en/latest/config.html#configuration-discovery>`_
   for running tests using `tox <https://tox.readthedocs.io>`_.
 
 - a ``README`` describing how to use the plugin and on which
@@ -280,7 +280,7 @@ Here is a simple overview, with pytest-specific bits:
 #. You can now edit your local working copy and run the tests again as necessary. Please follow `PEP-8 <https://www.python.org/dev/peps/pep-0008/>`_ for naming.
 
    You can pass different options to ``tox``. For example, to run tests on Python 3.13 and pass options to pytest
-   (e.g. enter pdb on failure) to pytest you can do::
+   (e.g. enter pdb on failure) you can do::
 
     $ tox -e py313 -- --pdb
 
@@ -346,7 +346,7 @@ For example, to ensure a simple test passes you can write:
         result.assert_outcomes(failed=0, passed=1)
 
 
-Alternatively, it is possible to make checks based on the actual output of the termal using
+Alternatively, it is possible to make checks based on the actual output of the terminal using
 *glob-like* expressions:
 
 .. code-block:: python
@@ -479,10 +479,10 @@ above?
    to do the backport.
 2. However, often the merge is done by another maintainer, in which case it is nice of them to
    do the backport procedure if they have the time.
-3. For bugs submitted by non-maintainers, it is expected that a core developer will to do
+3. For bugs submitted by non-maintainers, it is expected that a core developer will do
    the backport, normally the one that merged the PR on ``main``.
-4. If a non-maintainers notices a bug which is fixed on ``main`` but has not been backported
-   (due to maintainers forgetting to apply the *needs backport* label, or just plain missing it),
+4. If a non-maintainer notices a bug which is fixed on ``main`` but has not been backported
+   (due to maintainers forgetting to apply the *needs backport* or *backport x.x.x* labels, or just plain missing it),
    they are also welcome to open a PR with the backport. The procedure is simple and really
    helps with the maintenance of the project.
 
@@ -512,7 +512,7 @@ can always reopen the issue/pull request in their own time later if it makes sen
 When to close
 ~~~~~~~~~~~~~
 
-Here are a few general rules the maintainers use deciding when to close issues/PRs because
+Here are a few general rules the maintainers use to decide when to close issues/PRs because
 of lack of inactivity:
 
 * Issues labeled ``question`` or ``needs information``: closed after 14 days inactive.
@@ -524,15 +524,15 @@ The above are **not hard rules**, but merely **guidelines**, and can be (and oft
 Closing pull requests
 ~~~~~~~~~~~~~~~~~~~~~
 
-When closing a Pull Request, it needs to be acknowledging the time, effort, and interest demonstrated by the person which submitted it. As mentioned previously, it is not the intent of the team to dismiss a stalled pull request entirely but to merely to clear up our queue, so a message like the one below is warranted when closing a pull request that went stale:
+When closing a Pull Request, we should acknowledge the time, effort, and interest demonstrated by the person who submitted it. As mentioned previously, it is not the intent of the team to dismiss a stalled pull request entirely but to merely to clear up our queue, so a message like the one below is warranted when closing a pull request that went stale:
 
     Hi <contributor>,
 
     First of all, we would like to thank you for your time and effort on working on this, the pytest team deeply appreciates it.
 
     We noticed it has been awhile since you have updated this PR, however. pytest is a high activity project, with many issues/PRs being opened daily, so it is hard for us maintainers to track which PRs are ready for merging, for review, or need more attention.
 
-    So for those reasons we, think it is best to close the PR for now, but with the only intention to clean up our queue, it is by no means a rejection of your changes. We still encourage you to re-open this PR (it is just a click of a button away) when you are ready to get back to it.
+    So for those reasons, we think it is best to close the PR for now, but with the only intention to clean up our queue, it is by no means a rejection of your changes. We still encourage you to re-open this PR (it is just a click of a button away) when you are ready to get back to it.
 
     Again we appreciate your time for working on this, and hope you might get back to this at a later time!
 

RELEASING.rst

@@ -117,7 +117,7 @@ To release a version ``MAJOR.MINOR.PATCH``, follow these steps:
 
 #. Create a branch ``release-MAJOR.MINOR.PATCH`` from the ``MAJOR.MINOR.x`` branch.
 
-   Ensure your are updated and in a clean working tree.
+   Ensure your local checkout is up to date and in a clean working tree.
 
 #. Using ``tox``, generate docs, changelog, announcements::
 

changelog/12444.bugfix.rst

@@ -1 +1 @@
-Fixed :func:`pytest.approx` which now correctly takes account Mapping keys order to compare them.
+Fixed :func:`pytest.approx` which now correctly takes into account :class:`~collections.abc.Mapping` keys order to compare them.

changelog/README.rst

@@ -16,12 +16,12 @@ Each file should be named like ``<ISSUE>.<TYPE>.rst``, where
 * ``feature``: new user facing features, like new command-line options and new behavior.
 * ``improvement``: improvement of existing functionality, usually without requiring user intervention (for example, new fields being written in ``--junit-xml``, improved colors in terminal, etc).
 * ``bugfix``: fixes a bug.
-* ``doc``: documentation improvement, like rewording an entire session or adding missing docs.
+* ``doc``: documentation improvement, like rewording an entire section or adding missing docs.
 * ``deprecation``: feature deprecation.
 * ``breaking``: a change which may break existing suites, such as feature removal or behavior change.
 * ``vendor``: changes in packages vendored in pytest.
 * ``packaging``: notes for downstreams about unobvious side effects
-  and tooling. changes in the test invocation considerations and
+  and tooling. Changes in the test invocation considerations and
   runtime assumptions.
 * ``contrib``: stuff that affects the contributor experience. e.g.
   Running tests, building the docs, setting up the development

doc/en/backwards-compatibility.rst

@@ -53,8 +53,8 @@ History
 =========
 
 
-Focus primary on smooth transition - stance (pre 6.0)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Focus primarily on smooth transition - stance (pre 6.0)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Keeping backwards compatibility has a very high priority in the pytest project. Although we have deprecated functionality over the years, most of it is still supported. All deprecations in pytest were done because simpler or more efficient ways of accomplishing the same tasks have emerged, making the old way of doing things unnecessary.
 

doc/en/deprecations.rst

@@ -139,7 +139,7 @@ In ``8.2`` the ``exc_type`` parameter has been added, giving users the ability o
 to skip tests only if the module cannot really be found, and not because of some other error.
 
 Catching only :class:`ModuleNotFoundError` by default (and letting other errors propagate) would be the best solution,
-however for backward compatibility, pytest will keep the existing behavior but raise an warning if:
+however for backward compatibility, pytest will keep the existing behavior but raise a warning if:
 
 1. The captured exception is of type :class:`ImportError`, and:
 2. The user does not pass ``exc_type`` explicitly.
@@ -358,7 +358,7 @@ The ``yield_fixture`` function/decorator
 
 ``pytest.yield_fixture`` is a deprecated alias for :func:`pytest.fixture`.
 
-It has been so for a very long time, so can be search/replaced safely.
+It has been so for a very long time, so it can be searched/replaced safely.
 
 
 Removed Features and Breaking Changes
@@ -774,7 +774,7 @@ The ``pytest._fillfuncargs`` function
 
 This function was kept for backward compatibility with an older plugin.
 
-It's functionality is not meant to be used directly, but if you must replace
+Its functionality is not meant to be used directly, but if you must replace
 it, use `function._request._fillfixtures()` instead, though note this is not
 a public API and may break in the future.
 
@@ -805,7 +805,7 @@ The ``--result-log`` option produces a stream of test reports which can be
 analysed at runtime, but it uses a custom format which requires users to implement their own
 parser.
 
-The  `pytest-reportlog <https://github.com/pytest-dev/pytest-reportlog>`__ plugin provides a ``--report-log`` option, a more standard and extensible alternative, producing
+The :pypi:`pytest-reportlog` plugin provides a ``--report-log`` option, a more standard and extensible alternative, producing
 one JSON object per-line, and should cover the same use cases. Please try it out and provide feedback.
 
 The ``pytest-reportlog`` plugin might even be merged into the core

doc/en/example/attic.rst

@@ -75,7 +75,7 @@ decorate its result.  This mechanism allows us to stay
 ignorant of how/where the function argument is provided -
 in our example from a `conftest plugin`_.
 
-sidenote: the temporary directory used here are instances of
+Side note: the temporary directories used here are instances of
 the `py.path.local`_ class which provides many of the os.path
 methods in a convenient way.
 

doc/en/example/customdirectory.rst

@@ -36,7 +36,7 @@ You can create a ``manifest.json`` file and some test files:
 .. include:: customdirectory/tests/test_third.py
     :literal:
 
-An you can now execute the test specification:
+And you can now execute the test specification:
 
 .. code-block:: pytest
 

doc/en/example/markers.rst

@@ -411,7 +411,7 @@ A test file using this local plugin:
     def test_basic_db_operation():
         pass
 
-and an example invocations specifying a different environment than what
+and an example invocation specifying a different environment than what
 the test needs:
 
 .. code-block:: pytest

doc/en/example/parametrize.rst

@@ -4,7 +4,7 @@
 Parametrizing tests
 =================================================
 
-``pytest`` allows to easily parametrize test functions.
+``pytest`` allows you to easily parametrize test functions.
 For basic docs, see :ref:`parametrize-basics`.
 
 In the following we provide some examples using
@@ -642,7 +642,7 @@ As the result:
 
 - Four tests were collected
 - One test was deselected because it doesn't have the ``basic`` mark.
-- Three tests with the ``basic`` mark was selected.
+- Three tests with the ``basic`` mark were selected.
 - The test ``test_eval[1+7-8]`` passed, but the name is autogenerated and confusing.
 - The test ``test_eval[basic_2+4]`` passed.
 - The test ``test_eval[basic_6*9]`` was expected to fail and did fail.