chore: fixed typos

source/community/release_notes/dogwood.rst

@@ -404,15 +404,15 @@ Transactions
 * To avoid exceptions when you create models, edX recommends that you use the
   following pattern.
 
-    ::
-
-     if need_to_create_model:
-        try:
-            with transaction.atomic():
-                MyFancyModel.create(**kwargs)
-        except IntegrityError:
-            # Model has already been created.
-            log.warning("Something...")
+  .. code-block:: python
+
+    if need_to_create_model:
+      try:
+          with transaction.atomic():
+              MyFancyModel.create(**kwargs)
+      except IntegrityError:
+          # Model has already been created.
+          log.warning("Something...")
 
 
 .. _Database Transactions: https://docs.djangoproject.com/en/1.8/topics/db/transactions

source/community/release_notes/eucalyptus.rst

@@ -197,7 +197,7 @@ This release includes the following changes to course discussions.
 Updates to Bulk Email
 =====================
 
-The way the bulk email feature is enabled and disabeld has change, see
+The way the bulk email feature is enabled and disabled has changed, see
 :doc:`bulk_email` for more details.
 
 Updates to Analytics Events and Database Tables

source/community/release_notes/ficus.rst

@@ -163,7 +163,7 @@ System Upgrades and Updates
 * With Ficus, the operating system for the Open edX platform changes from
   Ubuntu 12.04 to Ubuntu 16.04, the latest long-term support (LTS) version of
   Ubuntu.  Ubuntu 12.04 reaches its end of life in April of this year.
-  Unfortunately, upgrading Open edX from Ubuntu 12.04 to Ubunbu 16.04 is not
+  Unfortunately, upgrading Open edX from Ubuntu 12.04 to Ubuntu 16.04 is not
   possible. If your existing installation of Open edX is based on Ubuntu 12.04,
   we recommend that you build a new system.
 

source/community/release_notes/ginkgo.rst

@@ -84,7 +84,7 @@ Studio and Course Author Tools
 * The problem component for open response assessments has been renamed from
   "Peer Assessment" to "Open Response Assessment."
 
-* The instructor dashboard includes an **Open Response Assessent** tab to help
+* The instructor dashboard includes an **Open Response Assessment** tab to help
   locate and access open response assessments and provide data about learner
   progress in completing responses and peer assessments.
 

source/community/release_notes/hawthorn.rst

@@ -143,6 +143,6 @@ Several features are deprecated or deleted in the Open edX Hawthorn release.
   experience any change with the next release.
 * ``django-simple-history`` has been deprecated and removed.
 * The ``LogoutViewConfiguration`` model has been removed. Single logout is now
-  permanently enabled. This meants that logging out of the LMS or an IDA logs
+  permanently enabled. This means that logging out of the LMS or an IDA logs
   you out of all systems.
 

source/community/release_notes/maple.rst

@@ -244,7 +244,7 @@ Unpacking Errors
 
 - **Permission Denied** - This error occurs if the user does not have the required permissions to perform the course import. Once that case occurs, the system throws the error to the user.
 
-- **Incompatble File** - This error is raised if the file to unpack is not in tar.gz format. This check verifies that the process of unpacking does not execute if the file is not in a valid format.
+- **Incompatible File** - This error is raised if the file to unpack is not in tar.gz format. This check verifies that the process of unpacking does not execute if the file is not in a valid format.
 
 - **File Not Found** - This error occurs if the uploaded file is not available in the storage or has been deleted.
 
@@ -270,7 +270,7 @@ The errors can occur after the XML validation and during the data update in the
 
 - **Proctoring Provider Error** - This error is raised when a ``courserun.xml`` file contains an attribute ``proctoring_provider`` e.g. ``proctoring_provider="proctortrack"`` and that provider is not available/enabled on the server.
 
-- **Unknown Error** - An unforeseen error occured while updating the course.
+- **Unknown Error** - An unforeseen error occurred while updating the course.
 
 .. note::
 

source/community/release_notes/nutmeg.rst

@@ -40,7 +40,7 @@ In order for User Tours to properly work, the backpopulate user tours management
 
 .. code-block:: shell
 
-    $ python ./manage.py lms backpopulate_user_tours
+    python ./manage.py lms backpopulate_user_tours
 
 
 Dates Tab
@@ -50,7 +50,7 @@ The Dates Tab has been added as a default static tab on all courses. All new cou
 
 .. code-block:: shell
 
-    $ python manage.py cms backfill_course_tabs
+    python manage.py cms backfill_course_tabs
 
 The Dates Tab has also been removed from the legacy learner experience. It is only available in the Learner MFE. This is the first step in remove the legacy learner experience altogether, which will be completed in the Olive release.
 
@@ -119,7 +119,7 @@ Gradebook Micro-frontend (MFE)
 Administrators & Operators
 **************************
 
-* Various improvements and bugfixes have been applied to `Tutor`_, the officialy-supported Open edX distribution and installation method. Notable features include an overhauled Tutor Plugin API and a new CLI for mounting repositories during development. You can see the full list by viewing `Tutor's changelog, starting at v13.0.1`_ (the first Tutor release after Maple) and reading upwards until v14.0.0 (the first Tutor release supporting Nutmeg).
+* Various improvements and bugfixes have been applied to `Tutor`_, the officially-supported Open edX distribution and installation method. Notable features include an overhauled Tutor Plugin API and a new CLI for mounting repositories during development. You can see the full list by viewing `Tutor's changelog, starting at v13.0.1`_ (the first Tutor release after Maple) and reading upwards until v14.0.0 (the first Tutor release supporting Nutmeg).
 
 .. _Tutor's changelog, starting at v13.0.1: https://github.com/overhangio/tutor/blob/master/CHANGELOG.md#v1301-2021-12-20
 .. _Tutor: https://docs.tutor.overhang.io/
@@ -129,11 +129,11 @@ Administrators & Operators
 .. _learning sequences: https://github.com/openedx/edx-platform/blob/db32ff2cdf678fa8edd12c9da76a76eef0478614/openedx/core/djangoapps/content/learning_sequences/README.rst
 .. code-block:: shell
 
-    $ python manage.py cms simulate_publish
+    python manage.py cms simulate_publish
 
 * By setting the :code:`ENABLE_NEW_RELIC` to false, the new relic logging integration will be disabled across all MFEs.
 
-* It's now possible to add optional fields to the registations form that are always visible, and do not require the user to click the checkbox "Support education research by providing additional information." Use the new :code:`optional-exposed` setting in the `REGISTRATION_EXTRA_FIELDS`_ setting.
+* It's now possible to add optional fields to the registration form that are always visible and do not require the user to click the checkbox "Support education research by providing additional information." Use the new :code:`optional-exposed` setting in the `REGISTRATION_EXTRA_FIELDS`_ setting.
 
 .. _REGISTRATION_EXTRA_FIELDS: https://edx.readthedocs.io/projects/edx-platform-technical/en/latest/settings.html#setting-REGISTRATION_EXTRA_FIELDS
 

source/community/release_notes/old_releases.rst

@@ -6,7 +6,7 @@ and if you are currently running them, it's recommended that you update to the
 latest supported release.
 
 Supported releases will receive security updates and will have the latest bug
-fixes and features. These older releases will not recieve any of those.
+fixes and features. These older releases will not receive any of those.
 
 .. toctree::
    :maxdepth: 2

source/community/release_notes/olive.rst

@@ -42,7 +42,7 @@ Instead, :ref:`mfe-runtime-configuration` should now be used to manage MFE setti
 JWT access tokens expire in 1 hour
 ==================================
 
-The default expiration for JWT access tokens was changed from ten hours to one hour. This default setting can be overriden now, by setting :code:`JWT_ACCESS_TOKEN_EXPIRE_SECONDS`.
+The default expiration for JWT access tokens was changed from ten hours to one hour. This default setting can be overridden now, by setting :code:`JWT_ACCESS_TOKEN_EXPIRE_SECONDS`.
 
 Learner Experiences
 *******************
@@ -158,7 +158,7 @@ MFE runtime configuration support
 
 Where up until Nutmeg it was only possible to change a micro-frontend's settings at build time, it is now possible to do so at both server *and* browser runtime via a new configuration mechanism.  In addition to the added convenience, this significantly reduces the frequency at which MFE container images need to be rebuilt.  Many operators will never have to build them to begin with, as pre-built ones can be (and are) provided, thus saving up precious time and resources on deployment.
 
-This behavior is optional and controlled by the :code:`ENABLE_MFE_CONFIG_API` Django setting in the LMS, and the :code:`APP_ID` and :code:`MFE_CONFIG_API_URL` MFE build-time settings.  The actual runtime configuration can then be specified via the :code:`MFE_CONFIG` and :code:`MFE_CONFIG_OVERRIDES` variables in the LMS.  (These can also be overriden via `site configuration <https://edx.readthedocs.io/projects/edx-installing-configuring-and-running/en/latest/configuration/sites/configure_site.html>`_, with the effect that such configuration can be changed dynamically via the backing database.)  For more details, refer to the `corresponding architecture decision record <https://github.com/openedx/edx-platform/blob/open-release/olive.master/lms/djangoapps/mfe_config_api/docs/decisions/0001-mfe-config-api.rst>`_.
+This behavior is optional and controlled by the :code:`ENABLE_MFE_CONFIG_API` Django setting in the LMS, and the :code:`APP_ID` and :code:`MFE_CONFIG_API_URL` MFE build-time settings.  The actual runtime configuration can then be specified via the :code:`MFE_CONFIG` and :code:`MFE_CONFIG_OVERRIDES` variables in the LMS.  (These can also be overridden via `site configuration <https://edx.readthedocs.io/projects/edx-installing-configuring-and-running/en/latest/configuration/sites/configure_site.html>`_, with the effect that such configuration can be changed dynamically via the backing database.)  For more details, refer to the `corresponding architecture decision record <https://github.com/openedx/edx-platform/blob/open-release/olive.master/lms/djangoapps/mfe_config_api/docs/decisions/0001-mfe-config-api.rst>`_.
 
 .. _upgrade-note:
 

source/developers/how-tos/add-sphinx-docs-to-a-repo.rst

@@ -137,7 +137,7 @@ Steps
       if not os.environ.get('DJANGO_SETTINGS_MODULE'):
          os.environ['DJANGO_SETTINGS_MODULE'] = 'test_utils.test_settings'
 
-#. Run the build again to make sure youve got the standard logos and footers
+#. Run the build again to make sure you have the standard logos and footers
    setup.
 
    .. code::
@@ -155,7 +155,7 @@ Steps
 
 #. Add a title to each index.rst
 
-#. Start wiriting documentation!
+#. Start writing documentation!
 
 .. seealso::
 

source/developers/how-tos/enable-python-upgrade-automation.rst

@@ -37,7 +37,7 @@ Steps
 4. Commit the changes to a branch and get the PR reviewed and merged.
 
    .. image:: /_images/developer_how_tos/python-requirements-upgrade-make-pr.png
-      :alt: An image of the UI formaking a branche for your changes.
+      :alt: An image of the UI for making a branch for your changes.
 
 5. Next, add the `edx-requirements-bot` team to your repository with ``write``
    permissions.  It will be at the following url with ``<repo_name>`` replaced

source/developers/how-tos/enable-translations-new-repo.rst

@@ -203,8 +203,8 @@ on a fork by following the steps below:
 #. Temporarily edit the ``Makefile`` so the ``pull_translations`` step pulls from your fork e.g.
    ``atlas pull --repository=Zeit-Labs/openedx-translations``.
 
-#. If you're testing and Open edX plugin, run the ``$ make pull_translations`` command in
-   the ``edx-platform`` repo. Otherwise, run ``$ make pull_translations`` in the repository
+#. If you're testing an Open edX plugin, run the ``make pull_translations`` command in
+   the ``edx-platform`` repo. Otherwise, run ``make pull_translations`` in the repository
    you're testing e.g. ``frontend-app-learning``.
 
 #. Run the application (or plugin) and verify the translations you've added are working properly.

source/developers/how-tos/get-your-project-docs-on-rtd.rst

@@ -53,14 +53,14 @@ Steps
       test builds on pull requests for this repository.
 
 #. Once the documentation is published you should update any READMEs and other
-   links that need to point to this documentation. The new documetation will be
+   links that need to point to this documentation. The new documentation will be
    published at a url like ``https://docs.openedx.org/projects/<repo_name>/``
 
 .. Following the steps, you should add the result and any follow-up tasks needed.
 
 .. seealso::
 
-  `Debuging/Fixig Docs Builds <https://openedx.atlassian.net/wiki/spaces/DOC/pages/3014852990/Debugging+Fixing+Docs+and+Adding+Docs+CI>`_
+  `Debugging/Fixing Docs Builds <https://openedx.atlassian.net/wiki/spaces/DOC/pages/3014852990/Debugging+Fixing+Docs+and+Adding+Docs+CI>`_
         A guide to help you fix issues you might run into while setting documentation CI.
 
   :doc:`/developers/how-tos/add-sphinx-docs-to-a-repo`

source/developers/how-tos/maintain-a-repo.rst

@@ -124,8 +124,8 @@ the maintainer would like to have more input on.
 .. warning::
 
    Sometimes github teams are used to group multiple repos together and the CCs
-   wiki lists the team instead of each individula repo.  The teams that are
-   used for acess should be listed at the top of the wiki page.
+   wiki lists the team instead of each individual repo.  The teams that are
+   used for access should be listed at the top of the wiki page.
 
    You can also make an `Axim Request`_ to get a snapshot of the what users and
    teams currently have access to your repo if you need more details or have

source/developers/how-tos/maintain-translations-in-your-repo.rst

@@ -20,14 +20,14 @@ translations into the `edx-platform`_ repository:
 
 .. code-block:: bash
 
-    $ cd /path/to/edx-platform
-    $ make pull_translations
+    cd /path/to/edx-platform
+    make pull_translations
 
 The ``make pull_translations`` command will (roughly) run the following command:
 
 .. code-block:: bash
 
-    $ atlas pull translations/edx-platform/conf/locale:conf/locale
+    atlas pull translations/edx-platform/conf/locale:conf/locale
 
 ==============
 Is It Working?
@@ -38,8 +38,8 @@ for the presence of the translations:
 
 .. code-block:: bash
 
-    $ tree conf/locale  # or ls conf/locale
-    $ git status  # Should show the new files
+    tree conf/locale  # or ls conf/locale
+    git status  # Should show the new files
 
 Run your application and test translations by changing the user langauge from the Account Settings page.
 

source/developers/references/a11y-ref.rst

@@ -45,7 +45,7 @@ If you want a checkbox, use the ``<input type=checkbox>`` element. Do not try to
 recreate states and properties that are included with the native element, such
 as focus or state. If you attempt to do so, more than likely you will not fully
 replicate all of them. Native checkbox elements include a toggle for checked
-state upon ``space`` or ``enter`` keypresses, exposing its label and
+state upon ``space`` or ``enter`` key presses, exposing its label and
 "`checkedness <http://www.w3.org/TR/html5/forms.html#concept-fe-checked>`_" to
 the Accessibility API.
 
@@ -518,7 +518,7 @@ These are some automated tools for accessibility testing.
 * Your keyboard. For information about using your keyboard to test for
   accessibility, see `<http://webaim.org/techniques/keyboard/>`_.
 
-* `Accessibility features in Chrome's Developer Tools <https://developers.google.com/web/updates/2018/01/devtools#a11y-pane>`_ allow you to see the Accessibilty Tree, ARIA attributes, and computed properties
+* `Accessibility features in Chrome's Developer Tools <https://developers.google.com/web/updates/2018/01/devtools#a11y-pane>`_ allow you to see the Accessibility Tree, ARIA attributes, and computed properties
 
 * `Lighthouse auditing tools <https://developers.google.com/web/tools/lighthouse>`_ built into Chrome's Developer Tools offer automated accessibility testing.
 

source/developers/references/developer_guide/extending_platform/xblocks.rst

@@ -131,9 +131,9 @@ steps.
 
 #.  Install your block.
 
-    ::
+    .. code-block:: bash
 
-        $ vagrant ssh
+        vagrant ssh
         vagrant@precise64:~$ sudo -u edxapp /edx/bin/pip.edxapp install /path/to/your/block
 
 #.  Enable the block.

source/developers/references/developer_guide/internationalization/i18n.rst

@@ -407,9 +407,9 @@ everything (scraping and serving) is working properly.
 
 First, use the coverage tool to generate dummy files.
 
-.. code-block:: sh
+.. code-block:: bash
 
-    $ paver i18n_dummy
+    paver i18n_dummy
 
 This step creates new dummy translations in the Esperanto directory
 (edx-platform/conf/local/eo/LC_MESSAGES) and the RTL directory
@@ -418,10 +418,10 @@ should discard these files once you have finished testing.
 
 Next, restart the LMS and Studio to load in the new translation files.
 
-.. code-block:: sh
+.. code-block:: bash
 
-    $ paver devstack lms
-    $ paver devstack studio
+    paver devstack lms
+    paver devstack studio
 
 Append ``/update_lang/`` to the root LMS or Studio URL and use the form to set
 the preview language. The language code ``eo`` can be used to specify the test
@@ -594,7 +594,7 @@ other, but they also serve as markers for the string extraction process.
 
 For string extraction to work properly, the translation functions must be
 called only with literal strings. If you use them with a computed value, the
-string extracter will not have a string to extract.
+string extractor will not have a string to extract.
 
 The difference between the right way and the wrong way can be very subtle, as
 shown in these examples.

source/developers/references/developer_guide/testing/browsers.rst

@@ -9,5 +9,5 @@ Browser support for the Open edX software is defined by the
 frontend package. See this site for information about what browsers the
 latest version of the Open edX platform supports.
 
-Older versions of the Open edX software are not guarenteed to work on
+Older versions of the Open edX software are not guaranteed to work on
 the latest versions of Chrome, Firefox, or other browsers.

source/developers/references/developer_guide/testing/code-quality.rst

@@ -4,17 +4,21 @@
 Code Quality
 ************
 
-We use a variety of tools to check for errors and vulerabilities, and to enforce
+We use a variety of tools to check for errors and vulnerabilities, and to enforce
 a coding standard and coding style.
 
 To check the quality of your pull request, go to the top level of the edx-
-platform codebase and run the following command. ::
+platform codebase and run the following command.
 
-    $ paver run_quality
+.. code-block:: bash
+
+    paver run_quality
 
-Most other repos use the command ::
+Most other repos use the command
+
+.. code-block:: bash
 
-    $ make quality
+    make quality
 
 The following topics provide additional details on the tools that we use.
 
@@ -39,9 +43,11 @@ we can ensure that pull requests do not introduce new quality violations, and
 also clean up existing violations in the process of introducing other changes.
 
 To run diff-quality along with our other quality based tools, go to the top
-level of the edx-platform codebase and run the following command. ::
+level of the edx-platform codebase and run the following command.
 
-    $ paver run_quality
+.. code-block:: bash
+
+    paver run_quality
 
 You can also use the ``paver run_pep8`` and ``paver run_pylint`` commands to
 run only pep8 or pylint.
@@ -51,7 +57,9 @@ This will print a report of the quality violations that your branch has made.
 Although we try to be vigilant in resolving all quality violations, some
 Pylint violations are too challenging to resolve, so we opt to ignore them via
 use of a pragma. A pragma tells Pylint to ignore the violation in the given
-line. An example is::
+line. An example is.
+
+.. code-block:: python
 
     self.assertEquals(msg, form._errors['course_id'][0])  # pylint: disable=protected-access
 

source/documentors/decisions/0005-markdown-for-npm-readmes.rst

@@ -33,13 +33,12 @@ Rejected Alternatives
 * Using a placeholder README file that links to the GitHub repository README. This would
   require either having both a Markdown and RST README in each repository, or implementing
   Markdown readme generation into the build/publish process. It would also result in a
-  sub-par experience when browsing Open edX published packages on npmjs.com.
-
+  sub-par experience when browsing Open edX published packages on `npmjs.com <https://npmjs.com>`__.
 
 Consequences
 ************
 
-* The READMEs for npm packages published as a part of the Open edX project will be fully rendered on npmjs.com.
+* The READMEs for npm packages published as a part of the Open edX project will be fully rendered on `npmjs.com <https://npmjs.com>`__.
 * Any existing RST READMEs in Open edX repositories that publish packages to npm will need to be rewritten in Markdown.
 
 .. _npm documentation for README files: https://docs.npmjs.com/about-package-readme-files