Contributing

Keeplas is built in the open and welcomes contributors of every experience level. Here is how to get from a fork to a merged pull request.

The workflow

  1. Fork and clone. Fork the repo and set up your local environment with pnpm. See the Self-Hosting guide for the full bootstrap.
  2. Make focused changes. Follow the coding standards, write tests for new functionality, and keep commits atomic.
  3. Open a pull request. CI runs lint, typecheck, and tests automatically. A maintainer reviews and merges once approved.

Before you start

A few housekeeping items keep the project sustainable:

  • Read CONTRIBUTING.md for the workflow and code style
  • Sign the Contributor License Agreement (CLA)
  • Follow the Code of Conduct — be respectful and constructive

Restricted areas

Some directories are gated by CODEOWNERS and require founder approval, because they hold the cryptographic core:

  • packages/crypto/ — AES-256-GCM, Argon2id, ML-KEM-768, Shamir Secret Sharing
  • security/ — threat models, audit findings, key-handling documents

You can still propose changes there — they just get extra review. Expect a longer cycle and detailed feedback. Cryptographic primitives are not a place for cleverness.

What we're looking for

  • Bug fixes with a failing test that reproduces the issue
  • Documentation improvements, especially across the bilingual EN/FR surface
  • Translations for additional locales (the dictionary system supports any number of languages)
  • UX polish — accessibility, keyboard navigation, mobile flows
  • Performance — we care about bundle size, Lighthouse scores, and cold-start times

What gets longer review

  • Schema or migration changes in packages/convex
  • Anything in packages/crypto or security/
  • New external dependencies (especially anything that ships JS to the browser)
  • Changes to the audit envelope or auth flow

Reporting a vulnerability

Found a security issue? Email security@keeplas.com. Please do not open a public GitHub issue for vulnerabilities — responsible disclosure keeps users safe.

We acknowledge reports within 48 hours and aim for a patch within 30 days for high-severity findings.

Getting started

Look for the "good first issue" label in GitHub. Those issues have clear scope, no hidden context, and a maintainer ready to help.

editEdit this page on GitHub