diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 45f2ddc6..2bde5906 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,53 +1,34 @@
# Contributing
-This document goes over how you (and/or your organization) are expected to contribute. These guidelines are softly enforced and sometimes not required.
+This document intends to teach you the proper way to contribute to the project as a set of guidelines. While they aren't always enforced, your chances of your code being accepted are significantly higher when you follow these. For smaller changes, we might opt to squash your changes to apply the guidelines below to your contribution.
-## Localization
-We use Crowdin to handle translations into many languages, and you can join the [StreamFX project on Crowdin](https://crowdin.com/project/obs-stream-effects) if you are interested in improving the translations to your native tongue. As Crowdin handles all other languages, Pull Requests therefore should only include changes to `en-US.ini`.
+Repository & Commits
-## Commit Guidelines
-Commits should focus on a single change such as formatting, fixing a bug, a warning across the code, and similar things. This means that you should not include a fix to color format handling in a commit that implements a new encoder, or include a fix to a bug with a fix to a warning.
+As this is a rather large project, we have certain rules to follow when contributing via git.
### Linear History
-This project prefers the linear history of `git rebase` and forbids merge commits. This allows all branches to be a single line back to the root, unless viewed as a whole where it becomes a tree. If you are working on a branch for a feature, bug or other thing, you should know how to rebase back onto the main branch before making a pull request.
+We follow the paradigm of linear history which forbids branches from being merged, thus changes made on branches are `git rebase`d back onto the root. This simplifies the code history significantly, but makes reverting changes more difficult.
-### Commit Message & Title
-We require a commit message format like this:
+❌ `git merge`
+✅ `git rebase`
+
+### Commits
+A commit should be containing a single change, even if it spans multiple units, and has the following format:
```
-prefix: short description
+short description
optional long description
```
-The `short description` should be no longer than 80 characters, excluding the `prefix: ` part. The `optional long description` should be present if the change is not immediately obvious - however it does not replace proper documentation.
+The short description should be no longer than 120 characters and focus on the important things. The long description is optional, but should be included for larger changes.
-#### The correct `prefix`
-Depending on where the file is that you ended up modifying, or if you modified multiple files at once, the prefix changes. Take a look at the list to understand which directories cause which prefix:
+Coding
### Documentation
-Documentation should be present in areas where it would save time to new developers, and in areas where an API is defined. This means that you should not provide documentation for things like `1 + 1`, but for things like the following:
+The short form of the this part is **Code != Documentation**. Documentation is what you intend your Code to do, while Code is what it actually does. If your Code mismatches the Documentation, it is time to fix the Code, unless the change is a new addition in terms of behavior or functionality. Note that by this we don't mean to document things like `1 + 1` but instead things like the following:
```c++
int32_t idepth = static_cast(depth);
@@ -58,14 +39,18 @@ int32_t container_size = static_cast(pow(2l, (idepth + (idepth / 2))));
```c++
class magic_class {
- void do_magic_thing(float magic_number);
+ void do_magic_thing(float magic_number) {
+ // Lots and lots of SIMD code that does a magic thing...
+ }
}
```
-Both of these examples would be much easier to understand if they had proper documentation, and save hours if not even days of delving into code. Documentation is about saving time to new developers, and can't be replaced by code. Code is not Documentation!
+Documenting what a block of Code does not only helps you, it also helps other contributors understand what this Code is supposed to do. While you may be able to read your own Code (at least for now), there is no guarantee that either you or someone else will be able to read it in the future. Not only that, but it makes spotting mistakes and fixing them easier, since we have Documentation to tell us what it is supposed to do!
### Naming & Casing
-All long-term objects should have a descriptive name, which can be used by other developers to know what it is for. Temporary objects should also have some information, but do not necessarily follow the same rules.
+The project isn't too strict about variable naming as well as casing, but we do prefer a universal style across all code. While this may appear as removing your individuality from the code, it ultimately serves the purpose of making it easier to jump from one block of code to the other, without having to guess at what this code now does.
+
+Additionally we prefer it when things are named by what they either do or what they contain, instead of having the entire alphabet spelled out in different arrangements. While it is fine to have chaos in your own Code for your private or hobby projects, it is not fine to submit such code to other projects.
#### Macros
- Casing: ELEPHANT_CASE
@@ -249,6 +234,16 @@ Special rules for `class`
#### Members
All class members must be `private` and only accessible through get-/setters. The setter of a member should also validate if the setting is within an allowed range, and throw exceptions if an error occurs. If there is no better option, it is allowed to delay validation until a common function is called.
-## Building
-Please read [the guide on the wiki](https://github.com/Xaymar/obs-StreamFX/wiki/Building) for building the project.
+Localization
+
+We use Crowdin to handle translations into many languages, and you can join the [StreamFX project on Crowdin](https://crowdin.com/project/obs-stream-effects) if you are interested in improving the translations to your native tongue. As Crowdin handles all other languages, Pull Requests therefore should only include changes to `en-US.ini`.
+
+