Contributing

Thank you for your interest in contributing to this project! All types of contributions are welcome, no matter how big or small.

I highly encourage that you read this guide before submitting a PR. It won't take you more than five minutes to read!

These are mostly guidelines, not rules. Use your best judgment.

❤️ The most important ones

Please allow project maintainers to edit your pull request!
Consistent code formatting is important. I use automatic code formatters (prettier for Javascript, black for Python).
I use code climate to detect code smells. I really appreciate code that is written with readability in mind. I always think about how I can reduce cognitive complexity of my code before committing them.
I try to adhere to this commit style guide when I word my commit messages.
Each commit MUST sucessfully build, not just the last one! That way, we can checkout any commit and be confident that the app works at that point in time! Your PR will most likely NOT be merged if the CI build fails.
I prefer PRs with commits with fewer changes, so it's easier to code review. If the commit is easy to understand, the more confident I would be to merge it. All the changes in a single commit must be logically connected!
Of course, don't get too crazy with extremely small commits! That would just pollute the commit history. Squash the commits and push force if you need to.
If somebody else's changes were merged to the main repo before your pull request is approved. Please do NOT merge. Please REBASE instead! Merging vs Rebasing. It keeps the history tidy! git pull --rebase
I like it when people are nice to each other. I don't like mean or rude people.

Before contributing, it's probably better to discuss the change you wish to make in an issue first. An issue explaining what you want to accomplish, why you want to do it, and how would do it.
Thoughtfully-written explanations and the rationale of the pull request is always appreciated!
Explanations of issues and PRs don't have to be long. Two or three sentences might be sufficient in a lot of cases, probably.
Including corresponding tests in your PR is always appreciated.
For whatever purpose it may serve, here's a simple git workflow I try to stick to.