This document goes over how you are expected to contribute to the project. This document is softly enforced, and considered a guideline instead of a requirement.
We use Crowdin to handle translations into many languages. Please 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. Pull Requests therefore should only include changes to `en-US.ini`, and no other localization files should be touched.
Commits should focus on a single change, such as formatting, fixing a single bug, a single 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.
This project prefers the linear history of `git rebase`, and as such 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 learn how to rebase back onto the main branch before making a pull request.
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 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:
-`/CMakeLists.txt`, `/cmake` -> `cmake`
-`/.github/workflows` -> `ci`
-`/data/locale`, `/crowdin.yml` -> `locale`
-`/data/examples` -> `examples`
-`/data` -> `data` (if not part of another prefix)
-`/media` -> `media`
-`/source`, `/include` -> `code`
-`/templates` -> `templates` (or merge with `cmake`)
-`/third-party` -> `third-party`
-`/tools` -> `tools`
-`/ui` -> `ui` (if not part of a `code` change)
- Most other files -> `project`
Multiple prefixes should be separated by `, ` and sorted alphabetically so that a change to `ui` and `code` results in a prefix of `code, ui`. If only a single code file was changed or multiple related file with a common parent were changed, the `code` prefix should be replaced by the path to the file like in these examples:
Your code should contain the comments where they would save time, as well as documentation for "public" facing functionality. This means that you shouldn't explain things like `1 + 1`, but should provide explanations for complex things. Consider the following:
This would be much easier to read if it had a an explaination and didn't require parsing the math. Comments are all about saving time to developers not already invested into the code.
### Naming & Casing
Names for anything should describe the purpose or function of the thing, unless the thing is temporary such as iterators.
Pre-processor Macros are a "last stand" option, when all other options fail or would produce worse results. If possible and cleaner to do so, prefer the use of `constexpr` code.
### Classes
#### Members
Members of classes should be private and only accessible via get/set methods.