Fix Typos in the Developer's Guide

docs/source/doc_pages/dev_guide/code_guidelines_bash.rst

@@ -11,7 +11,7 @@ Bash Code Guidelines
 Formatters and Linters
 ----------------------
 
-When writting Bash code for this project, please
+When writing Bash code for this project, please
 
     * Format your code with |shfmt|.
 
@@ -30,7 +30,7 @@ When writting Bash code for this project, please
 
     The listed formatters and linters offer plugins for many popular
     text editors and integrated development environments (IDEs).  When
-    using these plugins, your code is formatted and lintted on the fly,
+    using these plugins, your code is formatted and linted on the fly,
     so you don't have to run the commands yourself.
 
 .. note::

docs/source/doc_pages/dev_guide/code_guidelines_md.rst

@@ -11,7 +11,7 @@ Markdown Code Guidelines
 Formatters and Linters
 ----------------------
 
-When writting markdown language, please
+When writing Markdown Language, please
 
     * Lint your code with |markdownlint|.
 
@@ -28,7 +28,7 @@ When writting markdown language, please
 
     The listed formatters and linters offer plugins for many popular
     text editors and integrated development environments (IDEs).  When
-    using these plugins, your code is formatted and lintted on the fly,
+    using these plugins, your code is formatted and linted on the fly,
     so you don't have to run the commands yourself.
 
 .. note::

docs/source/doc_pages/dev_guide/code_guidelines_py.rst

@@ -1,7 +1,7 @@
 .. _code-guide-py-label:
 
-Pyhon Code Guidelines
-=====================
+Python Code Guidelines
+======================
 
 .. contents:: Site Contents
     :depth: 2
@@ -15,7 +15,7 @@ Formatters and linters automatically enforce a specific code style and
 quality.  They help you to focus on your actual task - the coding -
 without having to think about the code style.
 
-When writting Python code for this project, please
+When writing Python code for this project, please
 
     * Format your code with |Black| (automatically enforces Python code
       style guide :pep:`8`).
@@ -43,7 +43,7 @@ When writting Python code for this project, please
 
     The listed formatters and linters offer plugins for many popular
     text editors and integrated development environments (IDEs).  When
-    using these plugins, your code is formatted and lintted on the fly,
+    using these plugins, your code is formatted and linted on the fly,
     so you don't have to run the commands yourself.
 
 .. note::
@@ -98,5 +98,5 @@ Other Python Code Guidelines
 Code Guidelines for Python Submit Scripts
 -----------------------------------------
 
-    * When writting a script, use :mod:`opthandler.get_opts` to read
+    * When writing a script, use :mod:`opthandler.get_opts` to read
       options from |config_file| and command-line.

docs/source/doc_pages/dev_guide/dev_install.rst

@@ -44,7 +44,7 @@ of the project:
     # Upgrade pip, setuptools and wheel.
     python3 -m pip install --upgrade pip setuptools wheel
 
-Everytime you start working on the project, you should first activate
+Every time you start working on the project, you should first activate
 the virtual environment.  After you have finished working on the
 project, you can deactivate the virtual environment by typing
 :bash:`deactivate`.
@@ -93,7 +93,7 @@ You can check if pre-commit works properly by running
 (It's ok if not all tests pass as long as pre-commit itself runs without
 error.)
 
-Note that all pre-commit hooks are also run automatically everytime you
+Note that all pre-commit hooks are also run automatically every time you
 push to the upstream repository as part of our Continuous Integration
 (CI) workflow which includes `pre-commit.ci`_.  Your changes might not
 be accepted before not all tests that are affected by your changes are
@@ -103,7 +103,7 @@ passing.
 Uninstall
 ---------
 
-To unistall the project, just remove the project directory:
+To uninstall the project, just remove the project directory:
 
 .. code-block:: bash
 

docs/source/doc_pages/dev_guide/doc_guidelines.rst

@@ -66,7 +66,7 @@ Documentation Style
       apply:
 
         - The "Parameters" section is replaced by an "Options" section.
-        - In the "Options" section, use a |RST_option_list| to list the
+        - In the "Options" section, use an |RST_option_list| to list the
           options with which the script can/must be called and their
           meaning.
         - The "Options" sections is followed by a "Config File" section

docs/source/doc_pages/dev_guide/git_workflow.rst

@@ -118,7 +118,7 @@ Topic branch naming conventions:
       round.  This means, once you started branch naming without a
       sub-token, you cannot add a sub-token later.  This is the reason
       why you should never name your branches simply ``fix``, ``feat``,
-      ``ref`` or ``doc``.
+      ``ref``, ``dep``, ``docs`` or ``chore``.
     * Use hyphens to separate words.
     * Use group tokens at the beginning of your branch names:
 
@@ -216,7 +216,7 @@ Commit message conventions:
       characters.  It should be capitalized and written in imperative
       present tense.  It should not end with a period.
     * Start the summary line with "[Path]: Change", e.g.
-      "[lmod/palma/README.rst]: Fix typo".  In this way other developers
+      "[lmod/palma/README.rst]: Fix Typo".  In this way other developers
       and maintainers immediatly know which file has been changed.  If
       you have a complex commit affecting several files, break it down
       into smaller commits (see above).  If the path is too long to get

docs/source/doc_pages/dev_guide/test_guidelines.rst

@@ -50,8 +50,8 @@ Running Tests
 -------------
 
 Tests are automatically run as `GitHub Actions`_ when pushing changes
-to the upstream repository.  However, sometimes it is also usefull to
-run them locally.
+to the upstream repository.  However, sometimes it is also useful to run
+them locally.
 
 
 Doctests