Docs: More work on various things

.github/CONTRIBUTING.md

@@ -1,22 +0,0 @@
-## Contributing to obs-websocket
-
-### Translating obs-websocket to your language
-Localization happens on Crowdin: https://crowdin.com/project/obs-websocket
-
-### Writing code for obs-websocket
-#### Coding Guidelines
-- Function and variable names: snake_case for C names, CamelCase for C++ names
-- Tabs are 8 columns wide
-- 80 columns max.
-
-#### Commit Guidelines
-- Commits follow the 50/72 standard:
-	- 50 characters max for the title
-	- One empty line after the title
-	- Description wrapped to 72 columns max per line.
-- Commit titles:
-	- Use present tense
-	- Prefix the title with a "scope" name
-		- e.g: "CI: fix wrong behaviour when packaging for OS X"
-		- Typical scopes: CI, General, Request, Event, Server
-		- Look at existing commits for more examples

.github/FUNDING.yml

@@ -0,0 +1,3 @@
+open_collective: obs-websocket
+github: Palakis
+custom: https://www.paypal.me/stephanelepin

CONTRIBUTING.md

@@ -1,25 +1,28 @@
-# Contributing
+# Contributing to obs-websocket
+
+### Translating obs-websocket to your language
+
+Localization happens on Crowdin: https://crowdin.com/project/obs-websocket
 
 ### Branches
 
-Development happens on `4.x-current`
+**Development happens on `4.x-current`**
 
-### Pull Requests
+### Writing code for obs-websocket
 
-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.
+#### Code Formatting Guidelines
 
-**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").
+- Function and variable names: snake_case for C names, MixedCaps for C++ names
+- Request and Event names should use MixedCaps names
+- Request and Event json properties should use camelCase. For more detailed info on property naming, see [Google's JSON Style Guide](https://google.github.io/styleguide/jsoncstyleguide.xml)
+- Tabs are 8 columns wide
+- 80 columns max code width. (Docs can be larger)
+- New and updated requests/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).
 
-### 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:
+#### Code Best-Practices
 
+- Favor return-early code and avoid wrapping huge portions of code in conditionals. As an example, this:
 ```cpp
 if (success) {
     return req->SendOKResponse();
@@ -27,12 +30,40 @@ if (success) {
     return req->SendErrorResponse("something went wrong");
 }
 ```
-
 is better like this:
-
 ```cpp
 if (!success) {
     return req->SendErrorResponse("something went wrong");
 }
 return req->SendOKResponse();
 ```
+
+#### Commit Guidelines
+
+- Commits follow the 50/72 standard:
+        - 50 characters max for the commit title (excluding scope name)
+        - One empty line after the title
+        - Description wrapped to 72 columns max width per line.
+- Commit titles:
+        - Use present tense
+        - Prefix the title with a "scope" name
+                - e.g: "CI: fix wrong behaviour when packaging for OS X"
+                - Typical scopes: CI, General, Requests, Events, Server
+
+**Example commit:**
+
+```
+Requests: Add GetTransitionPosition
+
+Adds a new request called `GetTransitionPosition` which gets the current
+transition's state from 0.0f to 1.0f. Works with both auto and manual
+transitions.
+```
+
+#### 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 newly named branch based on the upstream main one (e.g.: `feature/cool-new-feature`, `bugfix/fix-palakis-mistakes`, ...)
+- Only open a pull request if you are ready to show off your work. 
+- If your work is not done yet, but for any reason you need to PR it (like collecting discussions, testing with CI, getting testers),
+	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").