diff --git a/Home.md b/Home.md
index 51ea18f..bb848b6 100644
--- a/Home.md
+++ b/Home.md
@@ -25,7 +25,6 @@ Or use the links to the right to navigate our documentation.
 * Configurable using simple JSON files
 * Is awesome
 
-
 ---
 
 ## Documentation
@@ -52,7 +51,7 @@ 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
+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`.
diff --git a/SIMPL-Bridging.md b/SIMPL-Bridging.md
index 1ff68d7..ce4209a 100644
--- a/SIMPL-Bridging.md
+++ b/SIMPL-Bridging.md
@@ -5,12 +5,12 @@ Essentials allows for devices defined within the SIMPL# Pro application to be br
 Some of the main advantages are:
 
 1. The ability to instantiate devices from configuration.
-2. The ability to leverage C# concepts to handle data intensive tasks (Serialization/Deserialization of JSON/XML, cyrptography, etc.).
-3. The ability to reuse the same compiled SIMPL Windows program (regardless of target processor type) by offloading all the variables that may be room or hardware specific to Essentials.
-4. The ability to handle multiple communciation types generically without changing the SIMPL Program (TCP/UDP/SSH/HTTP/HTTPS/CEC, etc.)
-5. Much faster development cycle
-6. Reduced processor overhead
-7. Ability to easily share devices defined in Essentials between multiple other programs
+1. The ability to leverage C# concepts to handle data intensive tasks (Serialization/Deserialization of JSON/XML, cyrptography, etc.).
+1. The ability to reuse the same compiled SIMPL Windows program (regardless of target processor type) by offloading all the variables that may be room or hardware specific to Essentials.
+1. The ability to handle multiple communciation types generically without changing the SIMPL Program (TCP/UDP/SSH/HTTP/HTTPS/CEC, etc.)
+1. Much faster development cycle
+1. Reduced processor overhead
+1. Ability to easily share devices defined in Essentials between multiple other programs
 
 ## Implementation
 
@@ -133,11 +133,11 @@ We have four Essentials Devices configured:
 
 1. Pro3 with a Key of "processor"
 
-2. Panasonic Display with a Key of "panasonicDisplay01"
+1. Panasonic Display with a Key of "panasonicDisplay01"
 
-3. Com port with a Key of "vtcComPort"
+1. Com port with a Key of "vtcComPort"
 
-4. Bridge with a Key of "deviceBridge"
+1. Bridge with a Key of "deviceBridge"
 
 We want to have access to the com port for VTC Control from Simpl Windows and we want to control the display from Simpl Windows.  To accomplish this, we have created a bridge device and added the devices to be bridged to the "devices" array on the bridge.  As you can see we define the device key and the join start, which will determine which joins we will use on the resulting EISC to interact with the devices.  In the Bridge control properties we defined ipid 03, and we will need a corresponding Ethernet System Intercommunication in the Simpl Windows program at ipid 03.  
 
@@ -350,23 +350,23 @@ Example device config: <https://github.com/PepperDash/Essentials/blob/master/Pep
 
 1. It is important to realize that there are no safety checks (yet) when assigning joinStarts in bridge configurations.  If you were to put two devices on a bridge with overlapping joins, the most recently bridged join would overwrite previously bridged joins.  For now it is on the programmer to ensure there are no conflicting join maps.
 
-2. There is _no_ limit to the amount of times a device may be bridged to.  You may have the same device on multiple bridges across multiple applications without problem.  That being said, we recommend using common sense.  Accessing a single com port for VTC control via multiple bridges may not be wise...  
+1. There is _no_ limit to the amount of times a device may be bridged to.  You may have the same device on multiple bridges across multiple applications without problem.  That being said, we recommend using common sense.  Accessing a single com port for VTC control via multiple bridges may not be wise...  
 
-3. A bridge need not only bridge between applications on the same processor.  A bridge may bridge to an application on a completely separate processor; simply define the ip address in the Bridge control properties accordingly.
+1. A bridge need not only bridge between applications on the same processor.  A bridge may bridge to an application on a completely separate processor; simply define the ip address in the Bridge control properties accordingly.
 
-4. For devices included in Essentials, you will be able to find defined join maps below.  If you are building your own plugins, you will need to build the join map yourself.  It would be beneficial to review the wiki entry on the [Feedback Class](https://github.com/PepperDash/Essentials/wiki/Feedback-Classes) for this.
+1. For devices included in Essentials, you will be able to find defined join maps below.  If you are building your own plugins, you will need to build the join map yourself.  It would be beneficial to review the wiki entry on the [Feedback Class](https://github.com/PepperDash/Essentials/wiki/Feedback-Classes) for this.
 
-5. When building plugins, we highly recommend reusing JoinMaps, as this will make code more easily interchangeable.  For example; if you were to build a display plugin, we'd recommend you use/extend the existing DisplayControllerJoinMap.  This way, you can swap plugins without needing any change on the Simpl Windows side.  This is extremely powerful when maintaining Simpl Windows code bases for large deployments that may utilize differing equipment per room.  If you can build a Simpl Windows program that interacts with established join maps, you can swap out the device via config without any change needed to Simpl Windows.
+1. When building plugins, we highly recommend reusing JoinMaps, as this will make code more easily interchangeable.  For example; if you were to build a display plugin, we'd recommend you use/extend the existing DisplayControllerJoinMap.  This way, you can swap plugins without needing any change on the Simpl Windows side.  This is extremely powerful when maintaining Simpl Windows code bases for large deployments that may utilize differing equipment per room.  If you can build a Simpl Windows program that interacts with established join maps, you can swap out the device via config without any change needed to Simpl Windows.
 
-6. Related to item 5, you can use the same paradigm with respect to physical device communication.  If you were to have a DSP device in some rooms communicating over RS232 and some via SSH, it would be trival to swap the device from a Com port to an SSH client in the Essentials Devicee Config and update the Bridge Config to brigde to the desired communication method.  Again this would require no change on the Simpl Windows side as long as you maintain the same join Start in the Bridge Device Configuration.
+1. Related to item 5, you can use the same paradigm with respect to physical device communication.  If you were to have a DSP device in some rooms communicating over RS232 and some via SSH, it would be trival to swap the device from a Com port to an SSH client in the Essentials Devicee Config and update the Bridge Config to brigde to the desired communication method.  Again this would require no change on the Simpl Windows side as long as you maintain the same join Start in the Bridge Device Configuration.
 
 ## Common Use Cases
 
 1. There are 10 conference rooms that all operate the same, but have hardware differences that are impossible to account for in SIMPL Windows.  For example, each room might have a DM-MD8X8 chassis, but the input and output cards aren't all in the same order, or they might be different models but function the same.  You can use Essentials with a unique configuration file for each hardware configuration.  
 
-2. You have a floor of conference rooms that all share some centralized hardware like DSP, AV Routing and a shared CEN-GWEXER gateway with multiple GLS-OIR-CSM-EX-BATT occupancy sensors.  All the shared hardware can be defined in the Essentials configuration and bridged over an EISC to each program that needs access.  The same device can even be exposed to multiple programs over different EISCs.  
+1. You have a floor of conference rooms that all share some centralized hardware like DSP, AV Routing and a shared CEN-GWEXER gateway with multiple GLS-OIR-CSM-EX-BATT occupancy sensors.  All the shared hardware can be defined in the Essentials configuration and bridged over an EISC to each program that needs access.  The same device can even be exposed to multiple programs over different EISCs.  
 
-3. You have a SIMPL program that works for many room types, but because some rooms have different models of processors than others (CP3/CP3N/AV3/PRO3/DMPS3 variants), you have to maintain several versions of the program, compiled for each processor model to maintain access to features like the System Monitor slot.  You can use Essentials running in a slot on a processor to expose the System Monitor and many other features of the processor, regardless of model.  Now you only need to maintain a single SIMPL program defined for your most complex processor application (ex. PRO3)
+1. You have a SIMPL program that works for many room types, but because some rooms have different models of processors than others (CP3/CP3N/AV3/PRO3/DMPS3 variants), you have to maintain several versions of the program, compiled for each processor model to maintain access to features like the System Monitor slot.  You can use Essentials running in a slot on a processor to expose the System Monitor and many other features of the processor, regardless of model.  Now you only need to maintain a single SIMPL program defined for your most complex processor application (ex. PRO3)
 
 ## Device Type Join Maps
 
@@ -468,6 +468,6 @@ Example device config: <https://github.com/PepperDash/Essentials/blob/master/Pep
 
 ## Example SIMPL Windows Program
 
-We've provided an [example program](https://github.com/PepperDash/Essentials/wiki/Feedback-Classes) for SIMPL Windows that works with the provided example Essentials configuration file [SIMPLBridgeExample_configurationFile.json](https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json).  Load Essentials and the example SIMPL program to two slots on the same processor and you can get a better idea of how to take advantage of SIMPL Windows bridging.
+We've provided an [example program](https://github.com/PepperDash/EssentialsSIMPLWindowsBridgeExample) for SIMPL Windows that works with the provided example Essentials configuration file [SIMPLBridgeExample_configurationFile.json](https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json).  Load Essentials and the example SIMPL program to two slots on the same processor and you can get a better idea of how to take advantage of SIMPL Windows bridging.
 
 Next: [Essentials architecture](Arch-summary)