Updating how to contribute based on main

HOW_TO_CONTRIBUTE.md

@@ -15,11 +15,11 @@ or contact [[email protected]](mailto:[email protected]) with any addi
 
 ## Branching Strategy
 
-The CoE Starter Kit uses a vnext branch strategy meaning that each solution in the CoE Starter Kit is maintained in a vnext branch, or, next version branch. The vnext branches follows a naming convention that makes it easy to identify the relevant vnext branch for each solution, i.e. the vnext branch for CenterofExcellenceCoreComponents is named CenterofExcellenceCoreComponents.
+The CoE Starter Kit uses feature branches from the main branch.
 
-When creating new releases for the CoE Starter Kit the vnext branches are merged into main, effectively adding next version features and fixes to the latest release.
+When creating new releases for the CoE Starter Kit the main branch is tagged with the version of the release (e.g. [CoEStarterKit-July2021](https://github.com/microsoft/coe-starter-kit/releases/tag/CoEStarterKit-July2021)). Hotfixes are made to the tagged version while on-going development of new features and bug fixes are made via Pull Requests into main.
 
-Following the branching strategy means that **all Pull Requests are made to a vnext branch and never directly to the main branch.**
+Following the branching strategy means that **all Pull Requests are made to the main branch.**
 
 ## Getting your own copy of the source code
 
@@ -38,7 +38,7 @@ The simplest way to synchronize your fork with the upstream repository is via th
 
 ![fetch upstream changes](.attachments/HOW_TO_CONTRIBUTE/fetch-upstream-changes.png)
 
-Selecting **Compare** will allow you to compare the changes in the upstream repository agains your own fork and create a pull request to merge these into your own fork.
+Selecting **Compare** will allow you to compare the changes in the upstream repository against your own fork and create a pull request to merge these into your own fork.
 
 Selecting **Fetch and merge** will fetch all upstream changes and merge into your own fork without a pull request work flow.
 
@@ -47,11 +47,11 @@ To manage the synchronization of upstream changes on the command line please ref
 ## Local branch strategy
 
 When implementing your contributions in your forked repository it is recommended that you employ a feature branch strategy. This means that you will have a branch for each feature or bug fix that your contribute. This approach helps keep the review process as simple as possible.
-We recommend naming your feature branches in a way that identify the feature or bug fix your are working on by having the issue id in the branch name.
+We recommend naming your feature branches in a way that identify the feature or bug fix your are working on by having the issue id in the branch name (e.g. yourgithubhandle-projectname-issuenumber **jenschristianschroeder-aa4am-123**).
 
 ## Pull Requests
 
-When your contribution is complete and you are ready to submit your changes to the CoE Starter Kit repository you should make a Pull Request from your feature branch in your own fork into the relevant vnext branch in the CoE Starter Kit repository.
+When your contribution is complete and you are ready to submit your changes to the CoE Starter Kit repository you should make a Pull Request from your feature branch in your own fork into the main branch in the CoE Starter Kit repository.
 
 Before we can accept a pull request from you, you'll need to sign a Contributor License Agreement (CLA). It is an automated process and you only need to do it once.
 To enable us to quickly review and accept your pull requests, always create one pull request per issue and link the issue in the pull request. Never merge multiple requests in one unless they have the same root cause.