Thanks for your interest in contributing to a FreClean repository.
- Check existing issues and open PRs to avoid duplicate work.
- For a significant change, open an issue first to discuss the approach before writing code.
- Read the specific repository's
README.mdfor its setup, architecture, and any repo-specific conventions.
FreClean repositories never present a status as more advanced than it actually is. There are no invented figures and no feature is described as live before it is real. See freclean-docs/whitepaper/24-legal-policy-framework.md for the full principle. A contribution that violates this, such as marking a product "available" without real backing data or claiming a partnership is not confirmed, will be asked to change before merge, regardless of how small the change otherwise is.
- Fork or branch from
main. - Make your change, following the target repo's existing patterns (e.g.
freclean-api's CRUD factory pattern,freclean-admin's config-driven resource pages) rather than introducing a new one for a single case. - Add or update tests where the repo has a test suite.
- Run the repo's lint, typecheck, and test scripts locally before opening a PR. They also run in CI, but catching issues locally is faster.
- Fill out
PULL_REQUEST_TEMPLATE.mdcompletely.
Each repo's linter config (.eslintrc.json or equivalent) is the source of truth, so run it rather than guessing at style. No repository uses a technology "because it sounds impressive". See freclean-payment's hand-written Celo client as an example of preferring a small, direct solution over a heavier dependency. Apply the same judgment to new dependencies.
Do not open a public issue or PR that discloses a security vulnerability. See SUPPORT.md and freclean-security/SECURITY.md.