Do not use emphasis for headings (#34662)

- address a markdown accessibility issue

nits:
- accept most markdownlint fixes e.g. about using consistent list characters
- correct a few spelling errors

CONTRIBUTING.md

@@ -3,9 +3,11 @@
 One of the easiest ways to contribute is to participate in discussions on GitHub issues. You can also contribute by submitting pull requests with code changes.
 
 ## General feedback and discussions?
+
 Start a discussion on the [repository issue tracker](https://github.com/dotnet/aspnetcore/issues).
 
 ## Bugs and feature requests?
+
 ❗ **IMPORTANT: If you want to report a security related issue, please see the `Reporting security issues and bugs` section below.**
 
 Before reporting a new issue, try to find an existing issue if one already exists. If it already exists, upvote (👍) it. Also consider adding a comment with your unique scenarios and requirements related to that issue.  Upvotes and clear details on the issue's impact help us prioritize the most important issues to be worked on sooner rather than later. If you can't find one, that's okay, we'd rather get a duplicate report than none.
@@ -21,10 +23,11 @@ If you can't find an existing issue, log a new issue in the appropriate GitHub r
 Or browse the full list of repositories in the [aspnet](https://github.com/aspnet/) organization.
 
 ## Reporting security issues and bugs
-Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC)  [email protected]. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the [Security TechCenter](https://technet.microsoft.com/en-us/security/ff852094.aspx).
 
+Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC)  [email protected]. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the [Security TechCenter](https://technet.microsoft.com/security/ff852094.aspx).
 
 ## Other discussions
+
 Our team members also monitor several other discussion forums:
 
 * [ASP.NET Core forum](https://forums.asp.net/1255.aspx/1?ASP+NET+5)
@@ -35,7 +38,7 @@ Our team members also monitor several other discussion forums:
 We are always happy to see PRs from community members both for bug fixes as well as new features.
 To help you be successful we've put together a few simple rules to follow when you prepare to contribute to our codebase:
 
-**Finding an issue to work on**
+### Finding an issue to work on
 
   Over the years we've seen many PRs targeting areas of the framework, which we didn't plan to expand further at the time.
   In all these cases we had to say `no` to those PRs and close them. That, obviously, is not a great outcome for us. And it's especially bad for the contributor, as they've spent a lot of effort preparing the change.
@@ -45,36 +48,39 @@ Within that set, we have additionally marked issues which are good candidates fo
 
 If there is some other area not included here where you want to contribute to, first open an issue to describe the problem you are trying to solve and state that you're willing to contribute a fix for it. We will then discuss in that issue, whether we think it belongs in the platform and the best approach to solve it.
 
-**Before writing code**
+### Before writing code
 
-  This can save you a lot of time. We've seen PRs, where customers would solve an issue in a way, which either wouldn't fit into the framework because of how it's designed or it would change the framework in a way, which is not something we'd like to do. To avoid these situations, we encourage customers to discuss the preferred design with the team first. To do so, file a new `design proposal` issue, link to the issue you'd like to address and provide detailed information about how you'd like to solve a specific problem. We triage issues peridocially and it will not take long for a team member to engage with you on that proposal.
+  This can save you a lot of time. We've seen PRs, where customers would solve an issue in a way, which either wouldn't fit into the framework because of how it's designed or it would change the framework in a way, which is not something we'd like to do. To avoid these situations, we encourage customers to discuss the preferred design with the team first. To do so, file a new `design proposal` issue, link to the issue you'd like to address and provide detailed information about how you'd like to solve a specific problem. We triage issues periodically and it will not take long for a team member to engage with you on that proposal.
   When you get an agreement from our team members that the design proposal you have is solid, then go ahead and prepare the PR.
   To file a design proposal, look for the relevant issue in the `New issue` page or simply click [this link](https://github.com/dotnet/aspnetcore/issues/new?assignees=&labels=design-proposal&template=4_design_proposal.md):
   ![image](https://user-images.githubusercontent.com/34246760/107969904-41b9ae80-6f65-11eb-8b84-d15e7d94753b.png)
 
-**Before submitting the pull request**
+### Before submitting the pull request
 
 Before submitting a pull request, make sure that it checks the following requirements:
 
-- You find an existing issue with the "help-wanted" label or discuss with the team to agree on adding a new issue with that label
-- You post a high-level description of how it will be implemented, and receive a positive acknowledgement from the team before getting too committed to the approach or investing too much effort implementing it
-- You add test coverage following existing patterns within the codebase
-- Your code matches the existing syntax conventions within the codebase
-- Your PR is small, focused, and avoids making unrelated changes
+* You find an existing issue with the "help-wanted" label or discuss with the team to agree on adding a new issue with that label
+* You post a high-level description of how it will be implemented, and receive a positive acknowledgement from the team before getting too committed to the approach or investing too much effort implementing it
+* You add test coverage following existing patterns within the codebase
+* Your code matches the existing syntax conventions within the codebase
+* Your PR is small, focused, and avoids making unrelated changes
 
 If your pull request contains any of the below, it's less likely to be merged.
 
-- Changes that break backward compatibility
-- Changes that are only wanted by one person/company. Changes need to benefit a large enough proportion of ASP.NET developers.
-- Changes that add entirely new feature areas without prior agreement
-- Changes that are mostly about refactoring existing code or code style
-- Very large PRs that would take hours to review (remember, we're trying to help lots of people at once). For larger work areas, please discuss with us to find ways of breaking it down into smaller, incremental pieces that can go into separate PRs.
+* Changes that break backward compatibility
+* Changes that are only wanted by one person/company. Changes need to benefit a large enough proportion of ASP.NET developers.
+* Changes that add entirely new feature areas without prior agreement
+* Changes that are mostly about refactoring existing code or code style
+* Very large PRs that would take hours to review (remember, we're trying to help lots of people at once). For larger work areas, please discuss with us to find ways of breaking it down into smaller, incremental pieces that can go into separate PRs.
+
+### During pull request review
 
-**During pull request review**
 A core contributor will review your pull request and provide feedback. To ensure that there is not a large backlog of inactive PRs, the pull request will be marked as stale after two weeks of no activity. After another four days, it will be closed.
 
 ### Resources to help you get started
+
 Here are some resources to help you get started on how to contribute code or new content.
+
 * Look at the [Contributor documentation](/docs/README.md) to get started on building the source code on your own.
 * ["Help wanted" issues](https://github.com/dotnet/aspnetcore/labels/help%20wanted) - these issues are up for grabs. Comment on an issue if you want to create a fix.
 * ["Good first issue" issues](https://github.com/dotnet/aspnetcore/labels/good%20first%20issue) - we think these are a good for newcomers.
@@ -87,14 +93,14 @@ If you would like to contribute to one of our repositories, first identify the s
 
 You will need to sign a [Contributor License Agreement](https://cla.dotnetfoundation.org/) when submitting your pull request. To complete the Contributor License Agreement (CLA), you will need to follow the instructions provided by the CLA bot when you send the pull request. This needs to only be done once for any .NET Foundation OSS project.
 
-If you don't know what a pull request is read this article: https://help.github.com/articles/using-pull-requests. Make sure the repository can build and all tests pass. Familiarize yourself with the project workflow and our coding conventions. The coding, style, and general engineering guidelines are published on the [Engineering guidelines](https://github.com/dotnet/aspnetcore/wiki/Engineering-guidelines) page.
+If you don't know what a pull request is read this article: <https://help.github.com/articles/using-pull-requests>. Make sure the repository can build and all tests pass. Familiarize yourself with the project workflow and our coding conventions. The coding, style, and general engineering guidelines are published on the [Engineering guidelines](https://github.com/dotnet/aspnetcore/wiki/Engineering-guidelines) page.
 
 ### Tests
 
--  Tests need to be provided for every bug/feature that is completed.
--  Tests only need to be present for issues that need to be verified by QA (for example, not tasks)
--  If there is a scenario that is far too hard to test there does not need to be a test for it.
-  - "Too hard" is determined by the team as a whole.
+* Tests need to be provided for every bug/feature that is completed.
+* Tests only need to be present for issues that need to be verified by QA (for example, not tasks)
+* If there is a scenario that is far too hard to test there does not need to be a test for it.
+  * "Too hard" is determined by the team as a whole.
 
 ### Feedback
 

docs/APIBaselines.md

@@ -1,8 +1,9 @@
 # API Baselines
 
 This document contains information regarding API baseline files and how to work with them. For additional details on how these files works, consult:
--	https://github.com/dotnet/roslyn-analyzers/blob/master/src/PublicApiAnalyzers/PublicApiAnalyzers.Help.md
--	https://github.com/dotnet/roslyn-analyzers/blob/master/src/PublicApiAnalyzers/Microsoft.CodeAnalysis.PublicApiAnalyzers.md
+
+- <https://github.com/dotnet/roslyn-analyzers/blob/master/src/PublicApiAnalyzers/PublicApiAnalyzers.Help.md>
+- <https://github.com/dotnet/roslyn-analyzers/blob/master/src/PublicApiAnalyzers/Microsoft.CodeAnalysis.PublicApiAnalyzers.md>
 
 ## Add baseline files for new projects
 
@@ -25,7 +26,7 @@ This file contains new APIs since the last major version. Steps for working with
 
 A new entry needs to be added to the PublicAPI.Unshipped.txt file for a new API. For example:
 
-```
+```text
 #nullable enable
 Microsoft.AspNetCore.Builder.NewApplicationBuilder.New() -> Microsoft.AspNetCore.Builder.IApplicationBuilder!
 ```
@@ -34,7 +35,7 @@ Microsoft.AspNetCore.Builder.NewApplicationBuilder.New() -> Microsoft.AspNetCore
 
 A new entry needs to be added to the PublicAPI.Unshipped.txt file for a removed API. For example:
 
-```
+```text
 #nullable enable
 *REMOVED*Microsoft.Builder.OldApplicationBuilder.New() -> Microsoft.AspNetCore.Builder.IApplicationBuilder!
 ```
@@ -43,7 +44,7 @@ A new entry needs to be added to the PublicAPI.Unshipped.txt file for a removed
 
 Two new entry needs to be added to the PublicAPI.Unshipped.txt file for an updated API, one to remove the old API and one for the new API. This also applies to APIs that are now nullable aware. For example:
 
-```
+```text
 #nullable enable
 *REMOVED*Microsoft.AspNetCore.DataProtection.Infrastructure.IApplicationDiscriminator.Discriminator.get -> string!
 Microsoft.AspNetCore.DataProtection.Infrastructure.IApplicationDiscriminator.Discriminator.get -> string?
@@ -66,4 +67,4 @@ Microsoft.AspNetCore.DataProtection.Infrastructure.IApplicationDiscriminator.Dis
 
 ## Updating baselines after major releases
 
-This will be performed by the build team using scripts at https://github.com/dotnet/roslyn/tree/master/scripts/PublicApi (or an Arcade successor). The process moves the content of PublicAPI.Unshipped.txt into PublicAPI.Shipped.txt
+This will be performed by the build team using scripts at <https://github.com/dotnet/roslyn/tree/master/scripts/PublicApi> (or an Arcade successor). The process moves the content of PublicAPI.Unshipped.txt into PublicAPI.Shipped.txt

docs/APIReviewProcess.md

@@ -1,4 +1,5 @@
-## Description
+# Description
+
 Starting in 5.0, certain areas within the dotnet/aspnetcore and dotnet/extensions repos will require formal *incremental* API reviews before any PRs that change APIs are merged.
 
 API changes to the following areas are required to go follow this process:
@@ -8,27 +9,27 @@ API changes to the following areas are required to go follow this process:
 * area-healthchecks
 * area-grpc
 * area-mvc
-    * feature-model-binding
-    * feature-razor-pages
-    * feature-JSONPatch
-    * feature-discovery
-    * feature-formatters
-    * feature-api-explorer
-    * feature-tag-helpers
+  * feature-model-binding
+  * feature-razor-pages
+  * feature-JSONPatch
+  * feature-discovery
+  * feature-formatters
+  * feature-api-explorer
+  * feature-tag-helpers
 * area-razor.compiler
 * area-security
 * area-signalr
 * area-identity
 * area-servers
 
 ## Process
+
 The goal of the API Review process is to ensure that the new APIs are following common patterns and the best practices.
 Also, it's aimed to help and guide engineers towards better API design decisions. People should feel empowered to submit their APIs for review as besides all the benefits it's also a learning and knowledge sharing experience.
 
 The process is visualized in the below diagram:
 ![A sequence diagram illustrating the same process described below.](https://user-images.githubusercontent.com/34246760/66542496-95052c80-eae7-11e9-9c7c-549b82a8d492.png)
 
-
 1. API review process kicks in after the owner for the issue identifies that the work required for the issue will need an API change or addition. In such cases, the issue owner will handle (either himself/herself, or with the community member who has expressed interest in handling the work) driving a design proposal. When working with a community member, the issue owner is responsible for guiding them to an acceptable design.
 1. If the proposed design adds new APIs, mark those issues with the `api-suggestion` label
 1. When the issue owner thinks the proposal is in a good shape, he/she marks the issue with `api-ready-for-review` label. Also, the @asp-net-api-reviews team should be notified on the issue.
@@ -42,12 +43,12 @@ The process is visualized in the below diagram:
 
 Before marking an issue as `api-ready-for-review`, make sure that the issue has the following:
 
-- A short description that will help reviewers not familiar with this area.
-- The API changes in ref-assembly format. It's fine to link this to the generated ref-assembly-code in the PR. If the changes are to an area that does produce ref-assemblies, please write out what it would look like in ref-assembly format for us to review.
+* A short description that will help reviewers not familiar with this area.
+* The API changes in ref-assembly format. It's fine to link this to the generated ref-assembly-code in the PR. If the changes are to an area that does produce ref-assemblies, please write out what it would look like in ref-assembly format for us to review.
 
 ```txt
-Good: This is the API for the widget factory, users use it in startup code to 
-configure how their widgets work. We have an overload that accepts URI, but 
+Good: This is the API for the widget factory, users use it in startup code to
+configure how their widgets work. We have an overload that accepts URI, but
 not one that accepts string, so we're adding it for convenience.
 
 Bad: Adding a string overload for Widget.ConfigureFactory.
@@ -69,4 +70,4 @@ If you are assigned a community-submitted change to *champion* in our API-review
 
 ## API Review Meeting
 
-The API Review meeting is open to all members of the ASP.NET Core team. The meeting invite is sent out to all the team members to join. Every API review meeting should include the area owners of the API change proposals as mandatory attendees. To list of all pending API review proposals can be found at: https://aka.ms/aspnet/apireviews
+The API Review meeting is open to all members of the ASP.NET Core team. The meeting invite is sent out to all the team members to join. Every API review meeting should include the area owners of the API change proposals as mandatory attendees. To list of all pending API review proposals can be found at: <https://aka.ms/aspnet/apireviews>

docs/DailyBuilds.md

@@ -1,12 +1,11 @@
-How to get daily builds of ASP.NET Core
-=======================================
+# How to get daily builds of ASP.NET Core
 
 Daily builds include the latest source code changes. They are not supported for production use and are subject to frequent changes, but we strive to make sure daily builds function correctly.
 
 If you want to download the latest daily build and use it in a project, then you need to:
 
-- Obtain the latest [build of the .NET Core SDK](https://github.com/dotnet/core-sdk#installers-and-binaries).
-- Add a NuGet.Config to your project directory with the following content:
+* Obtain the latest [build of the .NET Core SDK](https://github.com/dotnet/core-sdk#installers-and-binaries).
+* Add a NuGet.Config to your project directory with the following content:
 
   ```xml
   <?xml version="1.0" encoding="utf-8"?>
@@ -24,7 +23,7 @@ If you want to download the latest daily build and use it in a project, then you
 Some features, such as new target frameworks, may require prerelease tooling builds for Visual Studio.
 These are available in the [Visual Studio Preview](https://www.visualstudio.com/vs/preview/).
 
-#### To debug daily builds using Visual Studio
+## To debug daily builds using Visual Studio
 
 * *Enable Source Link support* in Visual Studio should be enabled.
 * *Enable source server support* in Visual should be enabled.