From c45872df5545554d9908d5fee460f6bc19a53533 Mon Sep 17 00:00:00 2001 From: Saeed Vaziry <61919774+saeedvaziry@users.noreply.github.com> Date: Sun, 5 Nov 2023 10:57:38 +0100 Subject: [PATCH] Create CONTRIBUTING.md --- CONTRIBUTING.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..337684ed --- /dev/null +++ b/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.