(doc) Update pull request process documentation (dnnsoftware#3063)

.github/PULL_REQUEST_PROCESS.md

@@ -1,11 +1,11 @@
 # DNN Platform Pull Request Proceseses
 
-The goal of this document is to set standards for the review, processing, and approval of all Pull requests into the DNN_Platform GitHub repository, as well as associated commmunity open-source repositories.  These rules apply to ALL pull requests, regardless of the submitter, or complexity of the change.
+The goal of this document is to set standards for the review, processing, and approval of all Pull requests into the DNN_Platform GitHub repository, as well as associated community open-source repositories.  These rules apply to ALL pull requests, regardless of the submitter, or complexity of the change.
 
 ## Prerequisites
 The following items must all be true prior to a pull request being submitted to the DNN_Platform, if any of the following items are not true the pull request will be returned for edits referencing the specific missing item(s).
 
-* Changes should target the branch where they should be merged, bug fixes that have no breaking changes should usually target the release/x.x.x latest branch; breaking changes, new features and major behaviour changes should usually target the development branch. If you are not sure which to target, please ask in the issue comments before starting your changes.
+* Changes should target the branch where they should be merged, bug fixes that have no breaking changes should usually target the release/x.x.x latest branch; breaking changes, new features and major behavior changes should usually target the development branch. If you are not sure which to target, please ask in the issue comments before starting your changes.
 * Change should represent an entire solution for the issue at hand.  Partial requests will NOT be processed.
 * Change should have a supporting issue logged on the DNN_Platform GitHub account, documenting the issue resolved, following the procedures outlined on the [Contribute Page](CONTRIBUTING.md)
 * If your change was to an area that already was covered by tests those tests must be updated.  New tests for areas currently un-tested are appreciated
@@ -14,7 +14,7 @@ The following items must all be true prior to a pull request being submitted to
   * Issue #, referenced such as “Fixes #24”
   * Release Note: Suggested release note for the change such as “Improvement of user profile to improve performance when searching.”
   * Testing Steps: Suggested testing steps for validation of the change
-* Pull request must pass the Continuous Integration (CI) Build.  Failure of the build will result in no futher review of the pull request until the build has been corrected.
+* Pull request must pass the Continuous Integration (CI) Build.  Failure of the build will result in no further review of the pull request until the build has been corrected.
 * The .NET Foundation [Contributor License Agreement (CLA)] (https://cla.dotnetfoundation.org/) must be signed prior to code review.  An automated process will prompt for this as part of the Pull Request process.
 
 > NOTE: Changes to methods that have been marked as [Obsolete] will typically not be accepted due to inherit risks associated with code scheduled for removal.  If a critical bug/issue exists, please be sure to document & discuss using an RFC issue prior to submitting your contribution to ensure alignment with acceptance criteria.
@@ -56,8 +56,8 @@ Once a pull request has been reviewed by two designated approvers it may be merg
 
 > This **_MUST NOT_** be done by the submitter of the Pull Request for ANY reason!  
 
-### Execption for Build Process Pull Requests
-A special exception has been granted to reduce the number of Designed Approval reviews to 1 for all pull requests related to Build Support when incrementing versions in prepration of a release, or reconfiguration of the environment for the next version. 
+### Exception for Build Process Pull Requests
+A special exception has been granted to reduce the number of Designed Approval reviews to 1 for all pull requests related to Build Support when incrementing versions in preparation of a release, or reconfiguration of the environment for the next version. 
 
 Additionally a special exception has been granted to merge pull requests created by the Designated Approvers for the purposes of keeping release branches in sync when the pull request ONLY moves previously approved changes.  Such as moving bug fixes from a minor release into the next major release, or otherwise.
 
@@ -75,4 +75,4 @@ If an item was submitted that will be integrated into a future release that is n
 
 In this situation the reviewing team will approve the request, tag the request with a specific version milestone and add a comment noting when and why it will be included in the particularly identified release.
 
-This most often will apply to technology or dependency changes that require alignment with Major, Minor, Revision build inclusion.  
+This most often will apply to technology or dependency changes that require alignment with Major, Minor, Revision build inclusion.