Fix typos in multiple files of docs

docs/ReleasePlanning.md

@@ -7,7 +7,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
@@ -17,7 +17,7 @@ The process for identifying candidates for the next major release consists of mu
 At this stage all the issues are distributed to engineers by feature areas. Each engineer reviews all the issues within their feature area, and returns to the next meeting with individual priority labels assigned - fl-p1, fl-p2, fl-p3, where `fl` are their initials.
 
 All the issues which the engineer believes are lower than `Priority-3` - remain in the backlog. We also agree to approximately balance the distribution of the 3 priority labels on the issues that will be brought back by each engineer, so that it forces real prioritization exercise.
-The issues which engineers think are good candidates and fit in the above listed requirements are moved to the `.NET V Planning` milestone, where `V` is the updcoming version number (7 at the time of this writing) - `.NET 7 Planning`.
+The issues which engineers think are good candidates and fit in the above listed requirements are moved to the `.NET V Planning` milestone, where `V` is the upcoming version number (7 at the time of this writing) - `.NET 7 Planning`.
 
 ### Rough costing
 At this phase engineers apply rough cost estimates to the final list of issues that they have moved to the `.NET V Planning` milestone, by applying one of the `Cost: X` labels below, where X is the size:
@@ -27,7 +27,7 @@ This will be used later during the planning process.
 
 For issues which don't have a clear description of the associated work, it's important to drop a comment summarizing the work involved. This will help at a later time, in case a question about the cost will be raised.
 
-**Note**: while costing issues, it's important to reevaluate costs for those, which already have cost labels applied. Those are most probably from the past and may be outdated, not properly representing the cost any more.
+**Note**: while costing issues, it's important to reevaluate costs for those, which already have cost labels applied. Those are most probably from the past and may be outdated, not properly representing the cost anymore.
 
 ### Team Review & Priority adjustment
 Now, that all the issues are in the `.NET V planning` milestone, the team reviews each issue one at a time starting from the highest priority ones (Priority: 1).
@@ -40,4 +40,4 @@ So we calculate the capacity of the team in weeks for the upcoming year and use
 
 ### Define the cut line
 At this point we have all the candidate issues that we think are worth considering for the upcoming release. This number is quite large, so the teams usually won't have enough capacity to handle all this.
-We start stack ranking issues so the most important work remains on the top of the list. We then draw the cut line and that defines the rough list of things the team will work on during the upcoming release.
+We start stack ranking issues so the most important work remains on the top of the list. We then draw the cut line and that defines the rough list of things the team will work on during the upcoming release.

docs/Servicing.md

@@ -1,6 +1,6 @@
 # Servicing Process
 
-We maintain several on-going releases at once and produce patches for them. An essential part of our support committent to users is that we build high-quality patches that avoid breaking applications. This means we have to be extremely cautious with taking changes in patch releases. This document describes the "bar" (criteria for accepting servicing fixes) and the process for managing these changes.
+We maintain several on-going releases at once and produce patches for them. An essential part of our support commitment to users is that we build high-quality patches that avoid breaking applications. This means we have to be extremely cautious with taking changes in patch releases. This document describes the "bar" (criteria for accepting servicing fixes) and the process for managing these changes.
 
 See the [.NET Core release lifecycle](https://dotnet.microsoft.com/platform/support/policy/dotnet-core#lifecycle) for more details on the currently-supported .NET releases.
 
@@ -24,7 +24,7 @@ In addition, the following factors make a particular servicing fix *more likely*
 * It is required to support new OS distributions
 * If the issue is reported through [Microsoft Product Support](https://dotnet.microsoft.com/platform/support).
 
-Finally, infrastructure and test-only fixes are generally acceptable since they do not impact the customer use of the product. However, these should generally be focused on fixes that improve the *reliability* of building/testing the product.
+Finally, infrastructure and test-only fixes are generally acceptable since they do not impact the customer usage of the product. However, these should generally be focused on fixes that improve the *reliability* of building/testing the product.
 
 ### Long-Term Support Releases
 

docs/TriageProcess.md

@@ -17,7 +17,7 @@ The goals of these rules are listed below in priority order:
 
 ## Triage Process Details
 
-The feature teams should be able look through every single issue filed against this repository and be able to make a quick call regarding the nature of the issue.
+The feature teams should be able to look through every single issue filed against this repository and be able to make a quick call regarding the nature of the issue.
 We will first categorize the issues and further handle these depending on the category the issue is in. The subsections below represent these categories and the rules we apply for them during our triage meeting.
 
 ### Information Gathering
@@ -27,7 +27,7 @@ We'll try to respond quickly to such issues (within days). If a user has collect
 
 ### Feature requests
 
-As soon as we identify an issue represents an ask for a new feature, we will label the issue with the `enhancement` label.
+As soon as we identify an issue that represents an ask for a new feature, we will label the issue with the `enhancement` label.
 Most of the time, we will automatically move these issues into the `.NET 8 Planning` milestone for further review during one of our [sprint planning meetings](#milestone-planning).
 If we think the feature request is not aligned with our goals, we may choose to close it immediately.
 In some situations, however, we may choose to collect more feedback before acting on the issue. In these situations we will move the issue in the `Backlog` so that we can review it during the [release planning](#release-planning).
@@ -36,7 +36,7 @@ In some situations, however, we may choose to collect more feedback before actin
 
 If it's immediately clear that the issue is related to a bug in the framework, we will apply the `bug` label to the issue.
 
-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.
+At this point, we will try to make a call regarding its 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 8 Planning` 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 the `Backlog` milestone to further evaluate the impact by reviewing customer upvotes / comments at a later time.
 
@@ -65,10 +65,10 @@ For some feature requests and bug reports, depending on the user involvement, we
 
 ## Release Planning
 
-Once we approach to the end of the release cycle (such as for .NET 7) 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.
+Once we approach the end of the release cycle (such as for .NET 7) 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.
-Issues, which we will think are candidates for the upcoming release, will be moved to the `.NET 8 Planning` milestone. This process is documented in more details in the [Release Planning](https://github.com/dotnet/aspnetcore/blob/main/docs/ReleasePlanning.md) document.
+Issues, which we will think are candidates for the upcoming release, will be moved to the `.NET 8 Planning` milestone. This process is documented in more detail in the [Release Planning](https://github.com/dotnet/aspnetcore/blob/main/docs/ReleasePlanning.md) document.
 
 ## Cleanup
 As we go through all the issues in the Backlog milestone as part of our release planning process, we will also cleanup the milestone by closing low priority issues, which have stayed in the backlog for more than 2 releases. While some of these issues may seem reasonable, the fact that those haven't been addressed for such prolonged period of time indicate that they're not as important for the product as they may seem to be.