Fix multiple minor spelling mistakes

mastering/virtualenv.rst

@@ -4,7 +4,7 @@
 Virtual Environments
 ====================
 
-Conan offer three special Conan generators to create virtual environments:
+Conan offers three special Conan generators to create virtual environments:
 
 - ``virtualenv``:  Declares the :ref:`self.env_info<method_package_info_env_info>` variables of the requirements.
 - ``virtualbuildenv``: Special build environment variables for autotools/visual studio.

versioning/lockfiles/build_order.rst

@@ -30,7 +30,7 @@ In this section we are going to use the following packages, defining this depend
 
 The example in this section uses ``full_version_mode``, that is, if a package changes any part of its version, its consumers will
 need to build a new binary because a new ``package_id`` will be computed. This example will use version ranges, and
-it is not necessary to have revisions enabled. It also do not require a server, everything can be reproduced locally.
+it is not necessary to have revisions enabled. It also does not require a server, everything can be reproduced locally.
 
 
 .. code-block:: bash
@@ -214,7 +214,7 @@ defined. They lock the reference and the package-id, and they can be built from
 
 
 If we want to check if the new ``libb/0.2`` version affects to the ``app2`` and something needs to
-be rebuild, the process is identical:
+be rebuilt, the process is identical:
 
 .. code-block:: bash
 

versioning/lockfiles/ci.rst

@@ -13,7 +13,7 @@ case. It doesn't aim to present a complete solution or the only possible one, de
 project, the team, the requirements, the constraints, etc., other approaches might be recommended.
 
 In this section we are going to use the same packages than in the previous one, defining this
- dependency graph.
+dependency graph.
 
 .. image:: conan_lock_build_order.png
    :height: 200 px
@@ -48,7 +48,7 @@ need to build a new binary because a new ``package_id`` will be computed.
 
     $ conan config set general.default_package_id_mode=full_version_mode
 
-This example will use version ranges, and it is not necessary to have revisions enabled. It also do not require
+This example will use version ranges, and it is not necessary to have revisions enabled. It also does not require
 a server, everything can be reproduced locally, although the usage of different repositories will be introduced.
 
 
@@ -157,9 +157,9 @@ revision doing an export, creating a new *libb_base.lock* lockfile:
 Products pipeline
 -----------------
 There is an important question to be addressed: **when a package changes, what other packages
-consuming it should be rebuild to account for this change?**. The problem might be harder than
+consuming it should be rebuilt to account for this change?**. The problem might be harder than
 it seems at first sight, or from the observation of the graph above. It shows that ``libd/0.1``
-has a dependency to ``libb/0.1``, does it means that a new ``libb/0.2`` should produce a re-build
+has a dependency to ``libb/0.1``, does it mean that a new ``libb/0.2`` should produce a re-build
 of ``libd/0.1`` to link with the new version? Not always, if ``libd`` had a pinned dependency
 and not a version range, it will never resolve to the new version, and then it doesn't and it
 cannot be rebuilt unless some developer makes some changes to ``libd`` and bumps the requirement.

versioning/lockfiles/introduction.rst

@@ -27,7 +27,7 @@ Locking dependencies
 
 This example uses ``full_version_mode``, that is, if a package changes any part of its version, its consumers will
 need to build a new binary because a new ``package_id`` will be computed. This example will use version ranges, and
-it is not necessary to have revisions enabled. It also do not require a server, everything can be reproduced locally.
+it is not necessary to have revisions enabled. It also does not require a server, everything can be reproduced locally.
 
 
 .. code-block:: bash