How to contribute

External contributions follow CONTRIBUTING.rst and the MongoDB GitHub wiki. This section of the Droid wiki describes the code-level day-to-day: how to take work from idea to merged commit.

Pages in this section

• Development workflow — branching, PR review, and Evergreen patches.
• Testing — frameworks, suites, hooks, and how to run them locally.
• Debugging — logs, gdb/lldb, fail points, and db.currentOp().
• Patterns and conventions — error handling, IDL, smart pointers, and the OperationContext.
• Tooling — Bazel, Poetry, lint, code generation, and the modules tooling.

Definition of done

For a server change, "done" usually means:

1. Code compiles cleanly under the supported toolchains (bazel build install-devcore).
2. Lint, format, and IDL checks pass. bazel run format reformats; buildscripts/clang_format.py format-my formats only the changed files. The clang-tidy checks defined in .clang-tidy.in and the project-specific checks in buildscripts/clang_tidy.py must pass.
3. Tests pass locally. New behavior gets new C++ unit tests (*_test.cpp) and/or new jstests/ integration tests. See Testing.
4. Resmoke suites that exercise the changed code pass on Evergreen. Most PRs run a "burn-in" patch automatically.
5. Server tickets (SERVER-NNNNN) are referenced in the commit message.

For changes that span modules or change a public API, also:

• Run the modules tooling to ensure no module-visibility violations were introduced.
• For wire-protocol or IDL changes, run bazel run idl-check-compatibility and bazel run check_idl_compatibility (see evergreen/check_idl_compat.sh).

Reviewing

Reviewers expect:

• A descriptive commit message starting with the SERVER ticket and a one-line summary.
• A discussion of risk: which suites caught the bug, what fail points were used, and whether feature flags or FCV gating are needed.
• Tests written first when fixing a regression — the test should fail without the fix.
• A small footprint where possible; very large refactors should be broken up so that reviewers can reason about them.

For drift between the docs and the code, prefer fixing the code; if the doc is correct, update the doc in the same PR. The in-tree docs under docs/ are actively maintained.