spelling fixes: docs

additional fixes to grammar in windows-full.md per alexandair

docs/building/windows-core.md

@@ -85,7 +85,7 @@ You can run our cross-platform Pester tests with `Start-PSPester`.
 Building in Visual Studio
 -----------------------------
 
-We do not recommend building the Poweshell solution from Visual Studio. This may lead to package version mismatches with errors similar to:
+We do not recommend building the PowerShell solution from Visual Studio. This may lead to package version mismatches with errors similar to:
 ```
 C:\dev\powershell\src\System.Management.Automation\project.json(142,77): error NU1001: The dependency Microsoft.PowerShe
 ll.CoreCLR.AssemblyLoadContext >= 1.0.0-* could not be resolved.

docs/building/windows-full.md

@@ -70,7 +70,9 @@ What can you do with the produced binaries?
 
 **Important**: "We don’t support production deployments of these binaries on any platform". For PowerShell .NET (aka: FullCLR PowerShell) our recommendation is to continue using the PowerShell .NET version already shipping in Windows Client and Windows Server.
 
-The primary reason to build the PowerShell FullCLR binaries is to test backward compatibility, and interoperability between .NET and CoreCLR.  It is also important to mention some features like PowerShell Workflows are not currently available in the CoreCLR version. So we want to provide the ability for the Community to test CoreCLR PowerShell code changes while validating that these changes don't introduce regressions in .NET PowerShell (aka: as FullCLR PowerShell)
+The primary reason to build the PowerShell FullCLR binaries is to test backward compatibility, and interoperability between .NET and CoreCLR.
+It is also important to mention that some features like PowerShell Workflows are not currently available in the CoreCLR version.
+We want to provide the ability for the Community to test CoreCLR PowerShell code changes while validating that these changes don't introduce regressions in .NET PowerShell (aka: as FullCLR PowerShell).
 
 To run (for test purposes) the dev version of these binaries please follow the following steps:
 

docs/cmdlet-example/SendGreeting.cs

@@ -18,7 +18,7 @@ namespace SendGreeting
         }
         private string name;
 
-        // Overide the ProcessRecord method to process
+        // Override the ProcessRecord method to process
         // the supplied user name and write out a
         // greeting to the user by calling the WriteObject
         // method.

docs/maintainers/issue-management.md

@@ -10,7 +10,7 @@ We use the following labels for issue classifications:
 * `Issue-Bug`: the issue is reporting a bug
 * `Issue-Discussion`: the issue may not have a clear classification yet.
   The issue may generate a [RFC][ln-rfc] or maybe be reclassified as a bug or enhancement.
-* `Issue-Enhancment`: the issue is more of a feature request than a bug.
+* `Issue-Enhancement`: the issue is more of a feature request than a bug.
 * `Issue-Meta`: an issue used to track multiple issues
 * `Issue-Question`: ideally support can be provided via other mechanisms,
   but sometimes folks to open an issue to get a question answered and we will use this label for such issues.

docs/maintainers/releasing.md

@@ -62,7 +62,7 @@ Similarly, the PowerShell man-page is generated from the Markdown-like file
 [`assets/powershell.1.ronn`][man] using [Ronn][].
 The function `Start-PSBootstrap -Publish` will install both these tools.
 
-To modify any property of the packages, edit the `New-UnixPckage` function.
+To modify any property of the packages, edit the `New-UnixPackage` function.
 Please also refer to the function for details on the package properties
 (such as the description, maintainer, vendor, URL,
 license, category, dependencies, and file layout).