ci(*): updating contribution md and yml for new branch name

Author: ChronosSF

.github/CONTRIBUTING.md

@@ -48,23 +48,23 @@ Open both repositories ([DocFX Site Builder](https://github.com/IgniteUI/igniteu
 # <a name='#fixing'> Fixing bugs and adding new samples</a>
 ## <a name='#bug'> Bug fixing guidelines</a>
 
-1. Depending on where the bug was found `the current version` or the `ongoing release version`, checkout a development branches from `vNext` or/and `master` branch. `vNext` is the version that is going to be used upon release (next version), and `master` is the branch with the current state (current version available on production). If the change/fix is applicable only to the ongoing release branch (`vNext`) there is no need to cherry-pick to `master` branch as the change/fix/feature will be pushed to `master` branch upon release.
+1. Depending on where the bug was found `the current version` or the `ongoing release version`, checkout a development branches from `vnext` or/and `master` branch. `vnext` is the version that is going to be used upon release (next version), and `master` is the branch with the current state (current version available on production). If the change/fix is applicable only to the ongoing release branch (`vnext`) there is no need to cherry-pick to `master` branch as the change/fix/feature will be pushed to `master` branch upon release.
 2. Run lint
 3. Pull request your changes and reference the issue. Use the enforced commit message format with applicable type, scope, etc.
 4. Don't forget to make the necessary status updates, as described in the workflow section.
 
-> Note: Cherry-pick to `master` branch only changes with **high priority**. There is no need to cherry-pick into `master` every bug fix/change from `vNext`> A regular mass merge PRs are going to be made from `vNext` into `master`.
+> Note: Cherry-pick to `master` branch only changes with **high priority**. There is no need to cherry-pick into `master` every bug fix/change from `vnext`> A regular mass merge PRs are going to be made from `vnext` into `master`.
 
 **Example workflow for a bug with high priority**
 The process will look like this:
 
-1.	Checkout new branch from `vNext`. For code example purposes let's say the new branch is called `fixing-bug-5423-vNext`.
-2.	Commit your changes to your `fixing-bug-5423-vNext` branch.
-3.	Push and PR to the `vNext` branch.
+1.	Checkout new branch from `vnext`. For code example purposes let's say the new branch is called `fixing-bug-5423-vnext`.
+2.	Commit your changes to your `fixing-bug-5423-vnext` branch.
+3.	Push and PR to the `vnext` branch.
 4.	Switch to the `master` branch.
 5.  Create a new branch from `master`. For code example purposes let's say the new branch is called `fixing-bug-5423-master`.
-6.  Cherry pick your commit from the `fixing-bug-5423-vNext` branch: `git cherry-pick ..`
+6.  Cherry pick your commit from the `fixing-bug-5423-vnext` branch: `git cherry-pick ..`
 7.  Push to your `fixing-bug-5423-master` branch and PR to the `master` branch.
 
 ## <a name='#new-sample'> Adding new samples guidelines </a>
-Depending on where the the new sample should be added, `the current version` or the `ongoing release version`, checkout a development branches from `vNext` or/and `master` branch. `vNext` is the version that is going to be used upon release (next version), and `master` is the branch with the current state (current version). If the new sample is applicable only to the ongoing release branch (`vNext`) there is no need to cherry-pick to `master` branch as the new sample will be pushed to `master` branch upon release.
+Depending on where the the new sample should be added, `the current version` or the `ongoing release version`, checkout a development branches from `vnext` or/and `master` branch. `vnext` is the version that is going to be used upon release (next version), and `master` is the branch with the current state (current version). If the new sample is applicable only to the ongoing release branch (`vnext`) there is no need to cherry-pick to `master` branch as the new sample will be pushed to `master` branch upon release.

.github/workflows/build-app-crm.yml

@@ -6,14 +6,14 @@ name: App CRM CI
 # events but only for the master branch
 on:
   push:
-    branches: [ master, vNext ]
+    branches: [ master, vnext ]
     paths:
       - '**'
       - '!src/**'
       - '!live-editing/**'
       - '!projects/app-lob/**'
   pull_request:
-    branches: [ master, vNext ]
+    branches: [ master, vnext ]
     paths:
       - '**'
       - '!src/**'

.github/workflows/build-app-lob.yml

@@ -6,7 +6,7 @@ name: App LOB CI
 # events but only for the master branch
 on:
   push:
-    branches: [ master, vNext ]
+    branches: [ master, vnext ]
     paths:
       - '**'
       - '!src/**'
@@ -16,7 +16,7 @@ on:
       - 'live-editing/generators/AppDVConfigGenerators.ts'
       - '!projects/app-crm/**'
   pull_request:
-    branches: [ master, vNext ]
+    branches: [ master, vnext ]
     paths:
       - '**'
       - '!src/**'

.github/workflows/codeql.yml

@@ -13,10 +13,10 @@ name: "CodeQL"
 
 on:
   push:
-    branches: [ "master", "vNext" ]
+    branches: [ "master", "vnext" ]
   pull_request:
     # The branches below must be a subset of the branches above
-    branches: [ "master", "vNext" ]
+    branches: [ "master", "vnext" ]
   schedule:
     - cron: '37 17 * * 1'