Add Automated docs spellcheck via GitHub Actions (#10774)

* github action

* cSpell config

* fixes: "prioritization", pre-release, up-vote

.github/workflows/spellcheck.yml

@@ -0,0 +1,29 @@
+name: Documentation Checks
+
+on:
+    push:
+        branches:
+            - main
+        paths:
+            # This ensures the check will only be run when something changes in the docs content
+            - "docs/**/*"
+    pull_request:
+        branches:
+            - main
+        paths:
+            - "docs/**/*"
+jobs:
+    spellcheck:
+        name: "Docs: Spellcheck"
+        runs-on: ubuntu-latest
+        steps:
+            - uses: actions/checkout@v2
+              name: Check out the code
+            - uses: actions/setup-node@v1
+              name: Setup node
+              with:
+                  node-version: "16"
+            - run: npm install -g cspell
+              name: Install cSpell
+            - run: cspell --config ./cSpell.json "docs/**/*.md" --no-progress
+              name: Run cSpell

cSpell.json

@@ -0,0 +1,60 @@
+{
+    "version": "0.2",
+    "language": "en",
+    "words": [
+        "Blazor"
+    ],
+    "ignoreWords": [],
+    "patterns": [
+        {
+            "name": "Markdown links",
+            "pattern": "\\((.*)\\)",
+            "description": ""
+        },
+        {
+            "name": "Markdown code blocks",
+            "pattern": "/^(\\s*`{3,}).*[\\s\\S]*?^\\1/gmx",
+            "description": "Taken from the cSpell example at https://cspell.org/configuration/patterns/#verbose-regular-expressions"
+        },
+        {
+            "name": "Inline code blocks",
+            "pattern": "\\`([^\\`\\r\\n]+?)\\`",
+            "description": "https://stackoverflow.com/questions/41274241/how-to-capture-inline-markdown-code-but-not-a-markdown-code-fence-with-regex"
+        },
+        {
+            "name": "Link contents",
+            "pattern": "\\<a(.*)\\>",
+            "description": ""
+        },
+        {
+            "name": "Snippet references",
+            "pattern": "-- snippet:(.*)",
+            "description": ""
+        },
+        {
+            "name": "Snippet references 2",
+            "pattern": "\\<\\[sample:(.*)",
+            "description": "another kind of snippet reference"
+        },
+        {
+            "name": "Multi-line code blocks",
+            "pattern": "/^\\s*```[\\s\\S]*?^\\s*```/gm"
+        },
+        {
+            "name": "HTML Tags",
+            "pattern": "<[^>]*>",
+            "description": "Reference: https://stackoverflow.com/questions/11229831/regular-expression-to-remove-html-tags-from-a-string"
+        }
+    ],
+    "ignoreRegExpList": [
+        "Markdown links",
+        "Markdown code blocks",
+        "Inline code blocks",
+        "Link contents",
+        "Snippet references",
+        "Snippet references 2",
+        "Multi-line code blocks",
+        "HTML Tags"
+    ],
+    "ignorePaths": []
+}

docs/ReleasePlanning.md

@@ -5,7 +5,7 @@ This document details the process we use for identifying candidate issues for th
 
 ## Phases
 The process for identifying candidates for the next major release consists of multiple phases. In each phase, we filter issues out of the release by either moving them to the `Backlog`, or closing the issue.
-- Filtering & Individual priorization
+- Filtering & Individual prioritization
 - Rough costing
 - Team review & Priority adjustment
 - Capacity planning

docs/ReleaseSchedule.md

@@ -4,7 +4,7 @@ Versions of .NET MAUI are being released in sync with new .NET versions. More in
 
 ## Past .NET MAUI Releases
 
-Below you can find a list of all the previous releases of .NET MAUI, excluding prereleases.
+Below you can find a list of all the previous releases of .NET MAUI, excluding pre-releases.
 For a full list, including release notes, please refer to our [Releases page](https://github.com/dotnet/maui/releases).
 
 | Version | Release Date |

docs/TriageProcess.md

@@ -38,7 +38,7 @@ If it's immediately clear, that the issue is related to a bug in the framework,
 
 At this point, we will try to make a call regarding it's impact and severity. If the issue is critical, we may choose to include it in our current milestone for immediate handling or potentially patching.
 If the bug is relatively high impact, we will move the issue into the `.NET V Planning` (where V is the .NET version we're planning this for) milestone to review during our [sprint planning](#milestone-planning) meeting.
-If the impact is unclear or the is a very corner case scenario, we may move it to a next `.NET V Planning` or `Backlog` milestone to further evaluate the impact by reviewing customer upvotes / comments at a later time.
+If the impact is unclear or the is a very corner case scenario, we may move it to a next `.NET V Planning` or `Backlog` milestone to further evaluate the impact by reviewing customer up-votes / comments at a later time.
 
 ### Investigations
 
@@ -58,7 +58,7 @@ If we identify a documentation issue which too many customers are having trouble
 Our milestones are usually a month long.
 Before each milestone we have one or more planning meetings, where we look through all the accumulated issues in the `.NET V Planning` (where V is the .NET version we're planning this for) milestone and choose the most important and impactful ones to handle during the next milestone. This will be a mixture of feature requests, bug fixes, documentation issues as well as some investigations.
 
-Note, that we will investigate only issues, which have accumulated more than certain number of upvotes and/or comments, which will indicate that there is some wider impact associated with it.
+Note, that we will investigate only issues, which have accumulated more than certain number of up-votes and/or comments, which will indicate that there is some wider impact associated with it.
 We may not investigate issues which haven't received many votes/comments and choose to close these. The reason is that the impact is very scoped and potentially something is wrong in the user code. Consider asking these questions on StackOverflow, or if a bug is super important to you, please consider contributing to our project yourself.
 
 For some feature requests and bug reports, depending on the user involvement, we may choose to move these to the backlog at this point. What this means, is that they will not be looked at again up until the next major release planning.
@@ -67,7 +67,7 @@ For some feature requests and bug reports, depending on the user involvement, we
 
 Once we approach to the end of the release cycle (.NET Core 3, .NET 5) we will look through the accumulated issues in the `Backlog` milestone. This is a long process as the amount of issues accumulated in this milestone is quite large.
 
-We will try to prioritize issues with most community requests / upvotes assuming these are aligned with our goals.
+We will try to prioritize issues with most community requests / up-votes assuming these are aligned with our goals.
 Issues, which we will think are candidates for the upcoming release, will be moved to the `.NET V Planning` (where V is the .NET version we're planning this for) milestone. This process is documented in more details in the [Release Planning](ReleasePlanning.md) document.
 
 ## Cleanup