Update docs - initial pr draft commit

BUILDING.md

@@ -29,12 +29,18 @@ make -j4
 sudo make install
 ```
 
+On other linux OS's, use this cmake command instead:
+
+```shell
+cmake -DLIBOBS_INCLUDE_DIR="<path to the libobs sub-folder in obs-studio's source code>" -DCMAKE_INSTALL_PREFIX=/usr ..
+```
+
 ## OS X
 
 As a prerequisite, you will need Xcode for your current OSX version, the Xcode command line tools, and [Homebrew](https://brew.sh/).
 Homebrew's setup will guide you in getting your system set up, you should be good to go once Homebrew is successfully up and running.
 
-Use of the Travis macOS CI scripts is recommended. Please note that these
+Use of the macOS CI scripts is recommended. Please note that these
 scripts install new software and can change several settings on your system. An
 existing obs-studio development environment is not required, as
 `install-build-obs-macos.sh` will install it for you. If you already have a
@@ -57,6 +63,4 @@ This will result in a ready-to-use `obs-websocket.pkg` installer in the `release
 
 ## Automated Builds
 
-- Windows: [![Automated Build status for Windows](https://ci.appveyor.com/api/projects/status/github/Palakis/obs-websocket)](https://ci.appveyor.com/project/Palakis/obs-websocket/history)
+[![Build Status](https://dev.azure.com/Palakis/obs-websocket/_apis/build/status/Palakis.obs-websocket?branchName=4.x-current)](https://dev.azure.com/Palakis/obs-websocket/_build/latest?definitionId=2&branchName=4.x-current)
-- Linux: [![Automated Build status for Linux](https://travis-ci.org/Palakis/obs-websocket.svg?branch=master)](https://travis-ci.org/Palakis/obs-websocket)
-- macOS: [![Automated Build status for macOS](https://img.shields.io/azure-devops/build/Palakis/obs-websocket/Palakis.obs-websocket.svg)](https://dev.azure.com/Palakis/obs-websocket/_build)

CONTRIBUTING.md

@@ -0,0 +1,38 @@
+# Contributing
+
+### Branches
+
+Development happens on `4.x-current`
+
+### Pull Requests
+
+Pull Requests must never be based off your fork's main branch (in this case, `4.x-current`). Start your work in a new branch
+based on the upstream main one (e.g.: `cool-new-feature`, `fix-palakis-mistakes`, ...) and open a Pull Request once you feel ready to show your work.
+
+**If your Pull Request is not ready to merge yet, create it as a Draft Pull Request** (open the little arrow menu next to the "Create pull request" button, then select "Create draft pull request").
+
+### Code style & formatting
+
+Source code is indented with tabs, with spaces allowed for alignment.
+
+Regarding protocol changes: new and updated request types / events must always come with accompanying documentation comments (see existing protocol elements for examples).
+These are required to automatically generate the [protocol specification document](docs/generated/protocol.md).
+
+Among other recommendations: favor return-early code and avoid wrapping huge portions of code in conditionals. As an example, this:
+
+```cpp
+if (success) {
+    return req->SendOKResponse();
+} else {
+    return req->SendErrorResponse("something went wrong");
+}
+```
+
+is better like this:
+
+```cpp
+if (!success) {
+    return req->SendErrorResponse("something went wrong");
+}
+return req->SendOKResponse();
+```

README.md

@@ -46,47 +46,13 @@ See the [build instructions](BUILDING.md).
 
 ## Contributing
 
-### Branches
+See [the contributing document](/CONTRIBUTING.md)
-
-Development happens on `4.x-current`
-
-### Pull Requests
-
-Pull Requests must never be based off your fork's main branch (in this case, `4.x-current`). Start your work in a new branch
-based on the main one (e.g.: `cool-new-feature`, `fix-palakis-mistakes`, ...) and open a Pull Request once you feel ready to show your work.
-
-**If your Pull Request is not ready to merge yet, create it as a Draft Pull Request** (open the little arrow menu next to the "Create pull request" button, then select "Create draft pull request").
-
-### Code style & formatting
-
-Source code is indented with tabs, with spaces allowed for alignment.
-
-Regarding protocol changes: new and updated request types / events must always come with accompanying documentation comments (see existing protocol elements for examples).
-These are required to automatically generate the [protocol specification document](docs/generated/protocol.md).
-
-Among other recommendations: favor return-early code and avoid wrapping huge portions of code in conditionals. As an example, this:
-
-```cpp
-if (success) {
-    return req->SendOKResponse();
-} else {
-    return req->SendErrorResponse("something went wrong");
-}
-```
-
-is better like this:
-
-```cpp
-if (!success) {
-    return req->SendErrorResponse("something went wrong");
-}
-return req->SendOKResponse();
-```
-
 
 ## Translations
 
-**Your help is welcome on translations**. Please join the localization project on Crowdin: https://crowdin.com/project/obs-websocket
+**Your help is welcome on translations.**
+
+Please join the localization project on Crowdin: https://crowdin.com/project/obs-websocket
 
 ## Special thanks