How to contribute

The repository's official contribution guidelines live at https://contributing.bitwarden.com/contributing/. The local CONTRIBUTING.md is a one-line pointer to that site. This wiki section captures the conventions and workflows that are visible in the codebase — the things you need to know to get a PR merged.

TL;DR

1. Fork from main (the only long-lived branch — release branches are cut from main and named rc-*).
2. Make your change. Match the existing code style; the formatter is enforced (dotnet format).
3. If your change touches the database, ship both an MS-SQL change script (util/Migrator/DbScripts/) and EF migrations for MySQL, Postgres, and SQLite.
4. Add or update tests under test/<Project>.Test and test/<Project>.IntegrationTest.
5. Open a PR against main. CI runs build, test, lint, scan, and code-references workflows. CODEOWNERS auto-requests reviews from the relevant team.
6. After approval and a green build, a maintainer merges; the publish workflow tags and pushes Docker images.

The rest of this section covers each step in detail:

• Development workflow — branching, schema changes, formatting, PR process, definition of done.
• Testing — unit vs. integration tests, fixtures, helpers, coverage expectations.
• Debugging — common errors, log surfaces, troubleshooting flows.
• Patterns and conventions — coding style, error handling, command/query split, authorization handlers.
• Tooling — build system, MSBuild SDKs, formatters, CI workflows.

What "good" looks like for a PR

• The title follows [<JIRA-KEY>] Short description (#<PR>) for staff PRs (see git log --oneline for the pattern). Community contributions can use plain prose.
• The diff is scoped to one change. Cross-team changes either coordinate with CODEOWNERS or get split.
• Public-API additions ship with Swagger annotations and at least one integration test.
• New SQL stored procedures are added in src/Sql/dbo/Stored Procedures/ and in util/Migrator/DbScripts/{date}_{slug}.sql and mirrored in EF (util/{Postgres,MySql,Sqlite}Migrations/).
• Two-factor / encryption-related code passes the AppSec checklist and is reviewed by @bitwarden/team-appsec.

Code review etiquette

• Match the area's CODEOWNERS list; teams are explicit (Auth, Vault, Tools, Admin Console, Billing, Platform, Key Management, Dirt, AppSec, BRE, DBOps, UI Foundation, AI SME, SDK SME).
• Reviewers prefer small, focused diffs and cite test results.
• Cross-team work (e.g. authorization handlers that affect organization users) needs sign-off from both @bitwarden/team-vault-dev and @bitwarden/team-admin-console-dev. CODEOWNERS encodes the joint-ownership rules.

For who owns what, see maintainers.