Thank you for your interest in contributing. This document covers the process and expectations for submitting changes.
- Check the issue tracker to see if the problem or feature is already being discussed.
- For significant changes, open an issue first to align on the approach before writing code.
- All contributions require agreement to the Contributor License Agreement.
- Fork the repository and create a branch from
main. - Name your branch descriptively:
fix/describe-the-fixorfeat/describe-the-feature. - Make your changes, keeping the scope focused — one fix or feature per PR.
- Open a pull request against
mainand fill out the PR template completely.
Follow Conventional Commits:
fix: short description of what was fixed
feat: short description of what was added
chore: dependency updates, config changes, etc.
- Use the imperative mood ("add support for" not "adds support for")
- Keep the subject line under 72 characters
- No trailing period
- CI must pass (backend and frontend checks)
- At least one approving review is required before merge
- The PR template must be filled out, including the CLA checkbox
- Keep changes minimal and focused — avoid unrelated cleanup in the same PR
- Match the style of the surrounding code
- Default to no comments — only add one when the reason behind something would genuinely surprise a future reader
- No half-finished implementations or feature flags for hypothetical future use
- Backend: Node/Express with async/await; avoid adding new dependencies without discussion
- Frontend: React with hooks; Tailwind for styling; avoid unnecessary abstraction
Use the bug report template. Include steps to reproduce, expected behaviour, and actual behaviour. Screenshots or logs are helpful.
Use the feature request template. Explain the problem you are trying to solve, not just the solution.