Improve grammar, spelling, and punctuation in Contributing to Wagtail section (#9396)

Co-authored-by: Thibaud Colas <thibaudcolas@gmail.com>

docs/contributing/committing.md

@@ -127,14 +127,14 @@ git branch -d pr/xxxx
 
 ## When you have made a mistake
 
-It's ok! Everyone makes mistakes. If you realise that recent merged changes
+It's ok! Everyone makes mistakes. If you realise that recently merged changes
 have a negative impact, create a new pull request with a revert of the changes
 and merge it without waiting for a review. The PR will serve as additional
-documentation for the changes, and will run through the CI tests.
+documentation for the changes and will run through the CI tests.
 
 ## Add commits to someone else's pull request
 
-Github users with write access to wagtail/wagtail (core members) can add
+GitHub users with write access to wagtail/wagtail (core members) can add
 commits to the pull request branch of the contributor.
 
 Given that the contributor username is johndoe and his pull request branch is called foo:

docs/contributing/developing.md

@@ -105,12 +105,12 @@ using the `--postgres` argument:
 python runtests.py --postgres
 ```
 
-If you need to use a different user, password, host or port, use the `PGUSER`, `PGPASSWORD`, `PGHOST` and `PGPORT` environment variables respectively.
+If you need to use a different user, password, host, or port, use the `PGUSER`, `PGPASSWORD`, `PGHOST`, and `PGPORT` environment variables respectively.
 
 ### Testing against a different database
 
 ```{note}
-In order to run these tests, you must install the required client libraries and modules for the given database as described in Django's [Databases documentation](https://docs.djangoproject.com/en/stable/ref/databases/) or 3rd-party database backend's documentation.
+In order to run these tests, you must install the required client libraries and modules for the given database as described in Django's [Databases documentation](https://docs.djangoproject.com/en/stable/ref/databases/) or the 3rd-party database backend's documentation.
 ```
 
 If you need to test against a different database, set the `DATABASE_ENGINE`
@@ -224,7 +224,7 @@ We want to make Wagtail accessible for users of a wide variety of assistive tech
 
 We aim for Wagtail to work in those environments. Our development standards ensure that the site is usable with other assistive technologies. In practice, testing with assistive technology can be a daunting task that requires specialised training – here are tools we rely on to help identify accessibility issues, to use during development and code reviews:
 
--   [react-axe](https://github.com/dequelabs/react-axe) integrated directly in our build tools, to identify actionable issues. Logs its results in the browser console.
+-   [react-axe](https://github.com/dequelabs/react-axe) integrated directly into our build tools, to identify actionable issues. Logs its results in the browser console.
 -   [@wordpress/jest-puppeteer-axe](https://github.com/WordPress/gutenberg/tree/trunk/packages/jest-puppeteer-axe) running Axe checks as part of integration tests.
 -   [Axe](https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd) Chrome extension for more comprehensive automated tests of a given page.
 -   [Accessibility Insights for Web](https://accessibilityinsights.io/docs/en/web/overview) Chrome extension for semi-automated tests, and manual audits.

docs/contributing/documentation_guidelines.md

@@ -64,10 +64,10 @@ Use bullets for unordered lists, numbers when ordered. Prefer dashes `-` for bul
 
 ### Inline styles
 
-Use **bold** and _italic_ sparingly, inline `code` when relevant.
+Use **bold** and _italic_ sparingly and inline `code` when relevant.
 
 ```md
-Use **bold** and _italic_ sparingly, inline `code` when relevant.
+Use **bold** and _italic_ sparingly and inline `code` when relevant.
 ```
 
 ### Code blocks
@@ -252,7 +252,7 @@ Images are hard to keep up-to-date as documentation evolves, but can be worthwhi
 
 ### Autodoc
 
-With its [autodoc](https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html) feature, Sphinx supports writing documentation in Python docstrings for subsequent integration in the project’s documentation pages. This is a very powerful feature which we highly recommend using to document Wagtail’s APIs.
+With its [autodoc](https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html) feature, Sphinx supports writing documentation in Python docstrings for subsequent integration in the project’s documentation pages. This is a very powerful feature that we highly recommend using to document Wagtail’s APIs.
 
     ```{eval-rst}
     .. module:: wagtail.coreutils

docs/contributing/documentation_modes.md

@@ -14,10 +14,10 @@ We are following Daniele Procida's [Diátaxis documentation framework](https://d
 
 ## Choose a writing mode
 
-Each page of the Wagtail documentation should be written in single mode of information delivery.
+Each page of the Wagtail documentation should be written in a single mode of information delivery.
 Single pages with mixed modes are harder to understand.
 If you have documents that mix the types of information delivery,
-it’s best to split them up. Add links to the first section of each document to cross reference other documents on the same topic.
+it’s best to split them up. Add links to the first section of each document to cross-reference other documents on the same topic.
 
 Writing documentation in a specific mode will help our users to understand and quickly find what they are looking for.
 
@@ -25,15 +25,14 @@ Writing documentation in a specific mode will help our users to understand and q
 
 ## Tutorial
 
-Tutorials are designed to be **learning-oriented** resources which guide newcomers through a specific topic. To help effective learning, tutorials should provide examples to illustrate the subjects they cover.
+Tutorials are designed to be **learning-oriented** resources that guide newcomers through a specific topic. To help effective learning, tutorials should provide examples to illustrate the subjects they cover.
 
 Tutorials may not necessarily follow best practices. They are designed to make it easier to get started. A tutorial is concrete and particular. It must be repeatable, instil confidence, and should result in success, every time, for every learner.
 
 ### Do
 
 -   Use conversational language
--   Use contractions, speak in the first person plural,
-    be reassuring. For example: “We’re going to do this.”
+-   Use contractions, speak in the first person plural, and be reassuring. For example: “We’re going to do this.”
 -   Use pictures or concrete outputs of code to reassure people that they’re on the right track.
     For example: “Your new login page should look like this:” or “Your directory should now have three files”.
 

docs/contributing/general_guidelines.md

@@ -6,7 +6,7 @@ British English is preferred for user-facing text; this text should also be mark
 
 ### Latin phrases and abbreviations
 
-Try to avoid Latin phrases (such as `ergo` or `de facto`) and abbreviations (such as `i.e.` or `e.g.`), and use common English phrases instead. Alternatively find a simpler way to communicate the concept or idea to the reader. The exception is `etc.` which can be used when space is limited.
+Try to avoid Latin phrases (such as `ergo` or `de facto`) and abbreviations (such as `i.e.` or `e.g.`), and use common English phrases instead. Alternatively, find a simpler way to communicate the concept or idea to the reader. The exception is `etc.` which can be used when space is limited.
 
 Examples:
 

docs/contributing/python_guidelines.md

@@ -14,12 +14,12 @@ In addition, import lines should be sorted according to [isort](https://pycqa.gi
 If you have installed Wagtail's testing dependencies (`pip install -e '.[testing]'`), you can check your code by
 running `make lint`. You can also just check python related linting by running `make lint-server`.
 
-You can run all Python formatting with `make format`. Similar to linting you can format python/template only files
+You can run all Python formatting with `make format`. Similar to linting you can format python/template-only files
 by running `make format-server`.
 
 ## Django compatibility
 
-Wagtail is written to be compatible with multiple versions of Django. Sometimes, this requires running one piece of code for recent version of Django, and another piece of code for older versions of Django. In these cases, always check which version of Django is being used by inspecting `django.VERSION`:
+Wagtail is written to be compatible with multiple versions of Django. Sometimes, this requires running one piece of code for recent versions of Django, and another piece of code for older versions of Django. In these cases, always check which version of Django is being used by inspecting `django.VERSION`:
 
 ```python
 import django

docs/contributing/ui_guidelines.md

@@ -11,7 +11,7 @@ Wagtail’s user interface is built with:
 
 Here are the available commands:
 
--   `make lint` will run all linting, `make lint-server` lints templates, `make lint-client` lints JS/CSS.
+-   `make lint` will run all linting, `make lint-server` lints templates, and `make lint-client` lints JS/CSS.
 -   `make format` will run all formatting and fixing of linting issues. There is also `make format-server` and `make format-client`.
 
 Have a look at our `Makefile` tasks and `package.json` scripts if you prefer more granular options.
@@ -21,7 +21,7 @@ Have a look at our `Makefile` tasks and `package.json` scripts if you prefer mor
 We use [djhtml](https://github.com/rtts/djhtml) for formatting and [Curlylint](https://www.curlylint.org/) for linting.
 
 -   Write [valid](https://validator.w3.org/nu/), [semantic](https://html5doctor.com/element-index/) HTML.
--   Follow [ARIA authoring practices](https://w3c.github.io/aria-practices/), in particular [No ARIA is better than Bad ARIA](https://w3c.github.io/aria-practices/#no_aria_better_bad_aria).
+-   Follow [ARIA authoring practices](https://w3c.github.io/aria-practices/), in particular, [No ARIA is better than Bad ARIA](https://w3c.github.io/aria-practices/#no_aria_better_bad_aria).
 -   Use classes for styling, `data-` attributes for JavaScript behaviour, IDs for semantics only.
 -   For comments, use [Django template syntax](https://docs.djangoproject.com/en/stable/ref/templates/language/#comments) instead of HTML.