Three ways in.
Whity is one maintainer's project that is trying to become more than that. Bug reports are genuinely useful, plugins need no permission at all, and pull requests are welcome if you're willing to clear the testing bar.
Report something broken
Open an issue with what you expected, what happened, how to reproduce it, and your version, PHP version and deployment mode. Redact secrets and tenant data from logs.
Build a plugin
You need no permission and you owe nothing back. The SDK is MIT, the plugin exception means your plugin can be closed-source and sold, and conformance test cases ship with the SDK so you can prove isolation.
Send a pull request
Branch off develop, keep it current, and bring tests. The bar is below — it's specific on purpose, so a review is about your idea rather than a checklist.
Sign the CLA once. You keep your copyright.
Copyright doesn't pool. If ten people each keep their own and the project later needs to relicense, all ten have to agree — and one person who changed jobs, changed email, or simply says no can freeze it permanently. Projects have lost years to exactly that.
So the agreement asks for permission, not ownership. You keep your copyright and can reuse your contribution anywhere, forever. You grant the maintainer a licence to distribute it under the AGPL and other terms, which is what makes a commercial licence possible alongside the free core. And you confirm it was yours to send.
Conventions worth knowing.
# branch: type/WC-XX-short-description, off develop
feature/WC-7-memory-management
fix/WC-42-tenant-leak
docs/WC-31-contributing-guide
# commit: WC-XX: verb + what changed (imperative)
WC-7: implement reflection-based class loader
WC-42: bind tenant_id predicate in the notes repository
# house rule: no AI / tool attribution trailers.
# commits are authored by the human contributor.Two long-lived branches: develop for feature work, main for releases. Rebase to keep history linear rather than merging develop back in.
What a pull request has to clear.
It's a high bar for a pre-1.0 project, deliberately: the thing being protected is a shared database holding many organisations' data.
Tests for anything that changes behaviour
Unit and integration. The full suite must be green before merge — CI enables
failOnRiskyandfailOnWarning, so warnings fail the build rather than accumulating.Prove the security-critical properties
Integration tests must show that protected routes reject callers without the permission, and that one tenant can never read or mutate another's data. There are canonical test patterns to copy — you're not inventing the approach.
Real engines for data-layer logic
Data-layer behaviour is tested against a real database engine rather than mocks, because a mock that agrees with your assumptions proves nothing about the migration that ships.
Static analysis and generated artifacts
PHPStan at level 8 across the same scope CI uses. If your change affects routes, regenerate the OpenAPI spec in the same commit — a drift gate will catch it otherwise.
An ADR for architectural decisions
Choices that constrain future work get written down as an Architecture Decision Record, with the context and the alternatives — not just the outcome.
A harassment-free project.
Whity follows a contributor code of conduct: participation is a harassment-free experience regardless of age, disability, ethnicity, gender identity and expression, level of experience, nationality, appearance, race, religion, or sexual identity and orientation. Report conduct concerns to the maintainer directly.
Where to ask.
| Bug or feature | GitHub issues — search first |
| Question | GitHub Discussions, or an issue tagged question |
| Security | Report privately — never a public issue |
| Commercial | No paid support tier today; email the maintainer for custom work |
Contributor FAQ.
Do I need to sign a CLA to contribute to Whity?
Yes, once, before your first contribution is merged. You keep your copyright and can reuse your own work anywhere. What you grant is permission to relicense — so the project can offer a commercial licence alongside the AGPL without needing every past contributor to agree individually.
Do I have to contribute my plugin back to Whity?
No. The plugin SDK is MIT and the core's AGPL carries a plugin exception, so a plugin built against the SDK can stay closed-source and be sold under any terms you choose. Contributing it back is welcome but never required.
What is the bar for a pull request to be merged?
Unit and integration tests for anything that changes behaviour, with the full suite green — CI fails on warnings and risky tests. Behaviour changes must prove RBAC route protection and cross-tenant rejection. PHPStan runs at level 8 and generated artifacts such as the OpenAPI spec must be regenerated in the same commit.
How should I name branches and write commits for Whity?
Branch as type/WC-XX-short-description off the latest origin/develop, where WC-XX is the tracking issue. Commit messages use 'WC-XX: verb + what changed' in imperative mood. The project rule is that commits carry no AI or tool attribution trailers — they are authored by the human contributor.
Start with the guide.
Environment setup, the full workflow, code standards and the PR process live in the repo.