Create CONTRIBUTING.md

CONTRIBUTING.md

@@ -0,0 +1,23 @@
+# Contributing
+Thank you for your interest in contributing! There are a couple of contribution guidelines that make it easier to apply the incoming suggestions.
+
+If you want to contribute please start with the issues. Issues labeled with "Bug" are the higher priorities.
+
+## Issues
+1. Issues are the best place to propose a new feature.
+2. If you are adding a feature that there is no issue for yet, please first open an issue and label it as "feature" and lets discuss it before you implement it.
+3. Search the issues before proposing a feature to see if it is already under discussion. Referencing existing issues is a good way to increase the priority of your own.
+4. We don't have an issue template yet, but the more detailed your explanation, the more quickly we'll be able to evaluate it.
+5. Search for the issue that you also have. Give it a reaction (and comment, if you have something to add). We note that!
+
+## Pull Requests
+1. Open PRs represent issues that we're actively thinking about merging (at a pace we can manage). If we think a proposal needs more discussion, or that the existing code would require a lot of back-and-forth to merge, we might close it and suggest you make an issue.
+2. All PRs should be made against the `main` branch. This can be changed in the future.
+3. If you are making changes to the front-end layer, Please build the assets via `npm run build` and push it with the other changes.
+4. Write tests for your code. Tests can be Unit or Feature.
+5. Code refactors will be closed. For the architectural refactors open an issue first.
+6. Use `./vendor/bin/pint` to style your code before opening a PR otherwise the actions will fail.
+7. Typo fixes in documentation are welcome, but if it's at all debatable we might just close it.
+
+## Misc
+1. If you think we closed something incorrectly, feel free to (politely) tell us why! We're human and make mistakes.