Thanks for your interest in contributing.
- All contributions should align with the project's scope, goals, and technical direction.
- Bug fixes and documentation improvements can go straight to a PR, no prior discussion needed.
- Anything larger should start with an issue. See below for why.
- Keep changes focused on a single concern wherever possible.
PRs are tricky. Any change, whether a new feature or a small tweak, has to fit the project's scope, goals, and technical direction. The code needs to match libredesk's existing style and conventions, and its impact on performance, usability, and stability should be clear before it can be merged.
That makes reviewing a slow, careful process. Larger PRs are harder to reason about, and reviewing them properly, discussing changes, and confirming they're safe to merge often takes more effort than writing the PR did. Whether a PR is accepted, and on what timeline, is ultimately up to the maintainers. This isn't personal. Maintainers carry the long-term context for the project, so decisions on direction and trade-offs sit with them.
To keep things moving:
- Propose first. Open an issue describing what you want to build, why it fits libredesk, and how you plan to implement it, with relevant technical detail, before writing code. The change might not align with the project's direction, or it could already be in progress. Checking first saves everyone time.
- Keep PRs small. Send focused PRs with a clear, single scope wherever possible. Smaller PRs are easier to review and test. Bundling multiple features into one PR is strongly discouraged.
Thanks for helping keep libredesk focused and maintainable.