Fix markdownlint errors

Signed-off-by: jsetton <jeremy.setton@gmail.com>

README.md

@@ -43,7 +43,7 @@ You can read a bit more below about our external resources and how we get them.
 
 ### Automatically Generated Parts
 
-Those parts include __all__ add-on documentation files, no matter if they are from the `openhab-core` repo, the `openhab-addons` repo or any special binding repo like _habmin_, _zwave_ or the _alexa skill_.
+Those parts include **all** add-on documentation files, no matter if they are from the `openhab-core` repo, the `openhab-addons` repo or any special binding repo like _habmin_, _zwave_ or the _alexa skill_.
 
 We are keeping all those files at their original location, because it simply doesn't make sense to keep them here.
 Imagine you want to do an improvement of the zwave binding and have to update the readme file in a completely different place.
@@ -77,7 +77,7 @@ Afterwards we will redeploy the website with the latest content from the _final_
 
 There are two triggers available currently.
 The `merge docs` job is triggered after something has been added to the documentation through this repository.
-The `gather external docs` job is started with a __successful__ build of the openhab-distribution.
+The `gather external docs` job is started with a **successful** build of the openhab-distribution.
 A successful distribution build will include all the latest changes that have been made to external sources like add-ons.
 So when a distribution build is successful, it will trigger the gathering of all external sources.
 

configuration/websocket.md

@@ -58,7 +58,7 @@ It is set in the response message in case an error occurred and can therefore be
 The `source` is also optional.
 However, it is recommended to send it along with the message.
 Since all events on the event bus are sent over the WebSocket connection, events that are sent by the client are also transmitted.
-A [source filter](#filter-by-source-filter-source) can be used to prevent that.
+A [source filter](#filter-by-source-openhabwebsocketfiltersource) can be used to prevent that.
 
 If a message can't be understood by openHAB (e.g. because of a wrong payload encoding or wrong topic), an error message is sent:
 

developers/addons/addon.md

@@ -10,7 +10,7 @@ Every add-on has to provide meta information such as add-on type, id or name.
 Background information: The meta information of all add-ons is accessible through the `org.openhab.core.addon.AddonInfoRegistry` service.
 
 Although add-on definitions are usually specified in a declarative way (as described in this section), they can also be provided as `org.openhab.core.addon.AddonInfo`.
-Any `AddonInfo` must be registered as service at the *OSGi* service registry.
+Any `AddonInfo` must be registered as service at the _OSGi_ service registry.
 The full Java API for addon definitions can be found in the Java package `org.openhab.core.addon`.
 
 For the declarative way, you add your add-on information in form of an `addon.xml` file to the bundle's folder `/src/main/resources/OH-INF/addon/`.
@@ -58,7 +58,7 @@ The full XML schema for add-on definitions is specified in the [Add-on XSD](http
 
 **Hints:**
 
-- The attribute `uri` in the section `config-description` is optional, it *should not* be specified in add-on definition files because it's an embedded configuration. If the `uri` is *not* specified, the configuration description is registered as `type:addonID`, otherwise the given `uri` is used.
+- The attribute `uri` in the section `config-description` is optional, it _should not_ be specified in add-on definition files because it's an embedded configuration. If the `uri` is _not_ specified, the configuration description is registered as `type:addonID`, otherwise the given `uri` is used.
 - If a configuration description is already specified somewhere else and the add-on wants to (re-)use it, a `config-description-ref` should be used instead.
 - Normally the service id must not be defined, because it is implicitly set to "type.<addonId>".
   An add-on can register an OSGi service which implements the ManagedService interface and define the service.pid as e.g."binding.hue" to receive the configuration.

developers/contributing.md

@@ -149,7 +149,7 @@ then you just add a line to every git commit message:
 
 using your real name (sorry, no pseudonyms or anonymous contributions.) and an
 e-mail address under which you can be reached (sorry, no github noreply e-mail
-addresses (such as username@users.noreply.github.com) or other non-reachable
+addresses (such as `username@users.noreply.github.com`) or other non-reachable
 addresses are allowed).
 
 Additionally can also sign off commits automatically by adding the `-s` or `--signoff` parameter to your usual git commit commands.
@@ -193,7 +193,7 @@ You don't even need to know Git.
 - You can preview your changes under the "Preview changes" tab.
 - Add a title and optional description for your proposed change at the bottom of the editor.
 - The [sign off rules](#sign-your-work) described above do apply to documentation contributions as well.
-  Simply add an empty line and the sign off statement "Signed-off-by: Joe Smith \<joe.smith@email.com\>" at the end of your change description at the bottom of the editor.
+  Simply add an empty line and the sign off statement `Signed-off-by: Joe Smith <joe.smith@email.com>` at the end of your change description at the bottom of the editor.
   Note that as per the rules you have to provide your full name in the sign off and that full name has to match the name you configured in your GitHub profile for the DCO check to succeed.
 - Click the "Propose file change" button at the bottom of the editor, then click "Create pull request" on the next page, and then on the summary page click "Create pull request" one more time.