Merge remote-tracking branch 'origin/master' into nightly

docs/configuration.rst

@@ -63,13 +63,13 @@ This configuration parameter defines the name of the Docker image to run for the
 
 - ``DOCKER_IMAGE_OPENEDX_DEV`` (default: ``"openedx-dev:{{ TUTOR_VERSION }}"``)
 
-This configuration paramater defines the name of the Docker image to run the development version of the lms and cms containers.  By default, the Docker image tag matches the Tutor version it was built with.
+This configuration parameter defines the name of the Docker image to run the development version of the lms and cms containers.  By default, the Docker image tag matches the Tutor version it was built with.
 
 .. https://hub.docker.com/r/devture/exim-relay/tags
 
 - ``DOCKER_IMAGE_CADDY`` (default: ``"docker.io/caddy:2.6.2"``)
 
-This configuration paramater defines which Caddy Docker image to use.
+This configuration parameter defines which Caddy Docker image to use.
 
 - ``DOCKER_IMAGE_ELASTICSEARCH`` (default: ``"docker.io/elasticsearch:7.17.9"``)
 
@@ -99,7 +99,7 @@ This configuration parameter defines which Simple Mail Transfer Protocol (SMTP)
 
 - ``DOCKER_IMAGE_PERMISSIONS`` (default: ``"{{ DOCKER_REGISTRY }}overhangio/openedx-permissions:{{ TUTOR_VERSION }}"``)
 
-This configuration parameter defines the Docker image to be used for setting file permissions. The default image sets all containers to be run as unpriveleged users.
+This configuration parameter defines the Docker image to be used for setting file permissions. The default image sets all containers to be run as unprivileged users.
 
 Custom registry
 ***************

docs/dev.rst

@@ -86,7 +86,10 @@ Finally, the platform can also be started back up with ``launch``. It will take
 Debugging with breakpoints
 --------------------------
 
-To debug a local edx-platform repository, add a `python breakpoint <https://docs.python.org/3/library/functions.html#breakpoint>`__ with ``breakpoint()`` anywhere in the code. Then, attach to the applicable service's container by running ``start`` (without ``-d``) followed by the service's name::
+To debug a local edx-platform repository, first, start development in detached mode (with ``-d``), add a `python breakpoint <https://docs.python.org/3/library/functions.html#breakpoint>`__ with ``breakpoint()`` anywhere in the code. Then, attach to the applicable service's container by running ``start`` (without ``-d``) followed by the service's name::
+
+  # Start in detached mode:
+  tutor dev start -d
 
   # Debugging LMS:
   tutor dev start lms
@@ -180,7 +183,7 @@ To check whether you have used the correct syntax, you should run ``tutor mounts
 
   $ tutor mounts add /path/to/edx-platform
   $ tutor mounts list
-  - name: /home/data/regis/projets/overhang/repos/edx/edx-platform
+  - name: /path/to/edx-platform
   build_mounts:
   - image: openedx
     context: edx-platform

docs/intro.rst

@@ -129,7 +129,7 @@ Many commands can be further parameterized to specify their target and options,
   tutor k8s logs mysql          # View logs of MySQL in Kubernetes-managed deployment.
   tutor dev logs lms --tail 10  # View ten lines of logs of the LMS container in development mode.
 
-And that's it! You do not need to understand Tutor's entire command-line interface to get started. Using the ``--help`` option that's availble on every command, it is easy to learn as you go. For an in-depth guide, you can also explore the `CLI Reference <reference/index.rst>`_.
+And that's it! You do not need to understand Tutor's entire command-line interface to get started. Using the ``--help`` option that's available on every command, it is easy to learn as you go. For an in-depth guide, you can also explore the `CLI Reference <reference/index.rst>`_.
 
 I'm ready, where do I start?
 ----------------------------

docs/tutorials/plugin.rst

@@ -4,7 +4,7 @@
 Creating a Tutor plugin
 =======================
 
-Tutor plugins are the offically recommended way of customizing the behaviour of Tutor. If Tutor does not do things the way you want, then your first reaction should *not* be to fork Tutor, but instead to figure out whether you can create a plugin that will allow you to achieve what you want.
+Tutor plugins are the officially recommended way of customizing the behaviour of Tutor. If Tutor does not do things the way you want, then your first reaction should *not* be to fork Tutor, but instead to figure out whether you can create a plugin that will allow you to achieve what you want.
 
 You may be thinking that creating a plugin might be overkill for your use case. It's almost certainly not! The stable plugin API guarantees that your changes will keep working even after you upgrade from one major release to the next, with little to no extra work. Also, it allows you to distribute your changes to other users.
 
@@ -104,7 +104,7 @@ Modifying configuration
 
 In the previous section you've learned how to add custom content to the Tutor templates. Now we'll see how to modify the Tutor configuration. Configuration settings can be specified in three ways:
 
-1. "unique" settings that need to be generated or user-specified, and then preserved in config.yml: such settings do not have reasonable defaults for all users. Examples of such setttings include passwords and secret keys, which should be different for every user.
+1. "unique" settings that need to be generated or user-specified, and then preserved in config.yml: such settings do not have reasonable defaults for all users. Examples of such settings include passwords and secret keys, which should be different for every user.
 2. "default" settings have static fallback values. They are only stored in config.yml when they are modified by users. Most settings belong in this category.
 3. "override" settings modify configuration from Tutor core or from other plugins. These will be removed and restored to their default values when the plugin is disabled.