How to contribute

This page is a quick on-ramp. The authoritative reference is CONTRIBUTING.md and the rustc-dev-guide — read both before your first non-trivial PR.

The big picture

Contributing to rust-lang/rust is unusual because:

1. There are many teams. T-compiler, T-libs, T-libs-api, T-lang, T-types, T-bootstrap, T-rustdoc, T-infra, T-release, T-spec, …. Each has its own scope, conventions, and Zulip stream. Your PR will be routed to the right team automatically (see triagebot.toml).
2. Almost everything goes through review. Library API changes go through the libs-api FCP; language changes go through the RFC process; compiler internals go through code review on the PR.
3. Merging is automated. Only the merge queue (bors / rust-bors) merges to main, and only after a full CI matrix passes.

The PR lifecycle

sequenceDiagram
    participant Author
    participant GitHub
    participant Reviewer
    participant Bors as bors / rust-bors
    participant CI

    Author->>GitHub: Open PR
    GitHub->>Reviewer: triagebot assigns from team
    Reviewer-->>Author: Review comments
    Author-->>Reviewer: Push fixes
    Reviewer->>Bors: r=reviewer (approve)
    Bors->>CI: Queue PR, run full matrix
    CI-->>Bors: ✅ green
    Bors->>GitHub: Merge to main

Key automation points (configured in triagebot.toml and rust-bors.toml):

• Triagebot auto-assigns a reviewer from the relevant team based on which paths your PR touches (each team has a mentions list and a list of paths it owns).
• @rustbot ready / @rustbot author flips the S-waiting-on-review ↔ S-waiting-on-author labels.
• @bors r=alice requests a merge once approved. @bors try runs a full CI without merging — used for perf runs.
• Rollups — small, low-risk PRs are batched into a single rollup PR by rustbot to save CI capacity.

Picking up work

Good places to start:

• E-easy / E-mentor / E-help-wanted — issues triaged for newcomers.
• The Zulip #new members stream.
• The rustc-dev-guide getting-started page.
• The "tests/crashes" directory — fixing an ICE often makes a self-contained first PR.

Definition of done

A PR is mergeable when:

• All CI jobs pass
• A team member has r+'d it (or it's a rollup of pre-approved PRs)
• All files are formatted (./x fmt --check is green)
• Tidy passes (./x test tidy)
• Tests are added/updated (UI test, MIR-opt test, etc., as appropriate)
• Bless'd output (.stderr / .stdout) reflects intentional diagnostic changes
• For language changes: an RFC has merged or a lang-team FCP has completed
• For library API changes: a libs-api FCP has completed

The full matrix of CI jobs lives in src/ci/github-actions/ and runs Docker-based jobs from src/ci/docker/.

Release trains

graph LR
    Main["main (nightly, every day)"] -->|6 weeks| Beta["beta branch"]
    Beta -->|6 weeks| Stable["stable release"]

Three channels run continuously:

• Nightly — cut from main every day.
• Beta — cut from main every six weeks, lives for six weeks, gets bug-fix backports.
• Stable — promoted from beta every six weeks. Frozen except for emergency point releases (1.x.1, 1.x.2).

Backports are nominated through triagebot.toml ([backport.*] sections) and reviewed by T-release.

Where to look next

• Development workflow — branch / commit / PR cycle in detail
• Testing — running and writing tests
• Debugging — investigating compiler bugs
• Patterns and conventions — style and architecture norms
• Tooling — build system, formatters, linters