Merge remote-tracking branch 'origin/feature/FixJsonInConfigdoc' into feature/neil-edits

# Conflicts:
#	Home.md

ConfigurationStructure.md

@@ -8,7 +8,7 @@ At a high level, the idea is to define a template of all of the common configura
 
 ## Top Level Object Structure (Double Config)
 
-``` json
+``` 
 {
     // This object is deserialized to type PepperDash.Essentials.Core.Config.EssentialsConfig
 
@@ -64,7 +64,7 @@ The idea being that configuration values that are common to all systems can be s
 
 Below is an example of a double configuration containing both template and system properties.
 
-``` json
+``` 
 {
 	"template": {
 		"info": {
@@ -93,7 +93,7 @@ Below is an example of a double configuration containing both template and syste
 }
 ```
 Below is an example of the result of merging the above double configuration example into a single configuration.
-``` json
+``` 
 {
 	"info": {
 		"name": "System Name",							// Since this property existed in both the template and system, the system value replaces the template value after the merge
@@ -111,7 +111,7 @@ Below is an example of the result of merging the above double configuration exam
 ---
 ## Device Object Structure
 The devices array is meant to hold a series of device objects.  The basic device object structure is defined below.
-``` json
+``` 
 {
 	"key": "someUniqueString",	// *required* a unique string
     "name": "A friendly Name",	// *required* a friendly name meant for display to users
@@ -147,7 +147,7 @@ Some additional details about specific properties that are important to note:
 
 ## The Device Properties.Control Object
 The control object inside properties has some reserved properties that are used by configuration tools and Essentials that require some caution.
-``` json
+``` 
 {
     "properties": {				// *required* an object where the configurable properties of the device are contained
     	"control": {			// an object to contain all of the properties to connect to and control the device
@@ -183,7 +183,7 @@ The control object inside properties has some reserved properties that are used
 ## Device Merging
 The following examples illustrate how the device key and uid properties affect how devices are merged together in a double configuration scenario.  In order for a template device and a system device to merge, they must have the same key and uid values
 
-``` json
+``` 
 {
 	"template": {
 		"info": {
@@ -239,7 +239,7 @@ The following examples illustrate how the device key and uid properties affect h
 }
 ```
 Below is an example of the result of merging the above double configuration example into a single configuration.  
-``` json
+``` 
 {
 	"info": {
 		"name": "System Name",

Debugging.md

@@ -48,7 +48,7 @@ Debug.Console(0, "Hello {0}", world);
 // This overload takes an IKeyed as the second parameter and the resulting statement will
 // print the Key of the device in console to help identify the class instance the message
 // originated from
-Debug.Console(0, this, "Hello World);
+Debug.Console(0, this, "Hello World");
 // prints: [timestamp]App 1:[deviceKey]Hello World
 
 // Each of the above overloads has a corresponding variant that takes an argument to indicate

Home.md

@@ -52,9 +52,9 @@ The `master` branch always contain the latest stable version.  The `development`
 [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) will be used as the workflow for this collaborative project.  To contribute, follow this process:
 
 1. Fork this repository ([More Info](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/working-with-forks))
-2. Create a branch using standard GitFlow branch prefixes (feature/hotfix/bugfix) followed by a descriptive name.
-    - Example: `feature/add-awesomeness`,`bugfix/wow-im-dumb` or `hotfix/really-big-oops`
-    - When working on a new feature or bugfix, branch from the `development` branch.  When working on a hotfix, branch from `master`.
+2. Create a branch using standard GitFlow branch prefixes (feature/hotfix) followed by a descriptive name.
+    - Example: `feature/add-awesomeness` or `hotfix/really-big-oops`
+    -  When working on a new feature or bugfix, branch from the `development` branch.  When working on a hotfix, branch from `master`.
 3. Make commits as necessary (often is better). And use concise, descriptive language, leveraging issue notation and/or [Closing Keywords](https://help.github.com/articles/closing-issues-using-keywords) to ensure any issues addressed by your work are referenced accordingly.
 4. When the scope of the work for your branch is complete, make sure to rebase your branch in case further progress has been made since the repo was forked 
 5. Create a Pull Request to pull your branch into the appropriate branch in the main repository.

Plugins.md

@@ -21,7 +21,7 @@ One or more plugins can be loaded to the /user/ProgramX/plugins as .dlls or .cpl
 All plugin assemblies must contain a static method called LoadPlugin():
 
 ```csharp
-public class SomeDevice : Device , IBridge  //IBridge only needs to be implemented if
+public class SomeDevice : Device , IBridge  //IBridge only needs to be implemented if using a bridge
 {
     // This string is used to define the minimum version of the
     // Essentials Framework required for this plugin