How to contribute

The canonical, user-facing version of this is CONTRIBUTING.md at the repo root. This page summarises the workflow from a contributor's perspective and links to the deeper how-to pages.

What gets merged

The Zed maintainers tend to merge about half the PRs they receive. Things they explicitly welcome:

• Bug fixes with reproductions.
• Small feature improvements ("make this work for more people").
• Documentation fixes.
• Keybindings, actions, and editor ergonomics that are missing relative to other editors.

Things that need a discussion before code:

• Larger features. Read docs/src/development/feature-process.md and open a GitHub Discussion or Issue first.
• AI-assisted PRs where the author cannot defend the change. The team explicitly will not merge "vibe-coded" PRs.

The PR pipeline

graph LR
    A[Idea] -->|small bug| B[Open PR]
    A -->|big feature| C[Discussion / Issue]
    C --> D[Maintainer ack]
    D --> B
    B --> E[CI: tests, clippy, licenses]
    E --> F{Reviewer triage}
    F -->|merge| G[Merged to main]
    F -->|comments| B
    F -->|rejected| H[Closed with thanks]
    G --> I[Auto release notes]

Reviewer assignment is automated by .github/workflows/assign-reviewers.yml, drawing from REVIEWERS.conl. Areas are mapped to people (ai, gpui, lsp, …); changes that touch unmapped paths fall back to the <all> bucket.

PR hygiene

From .rules:

• Imperative, correctly-capitalized PR titles. Example: Fix crash in project panel.

• No conventional-commit prefixes (fix:, feat:, docs:).

• No trailing punctuation in PR titles.

• Optional crate-name prefix for single-crate scope, e.g. git_ui: Add history view.

• Every PR body ends with a Release Notes: section. Format:

  Release Notes:
  
  - Added support for X

  or

  Release Notes:
  
  - N/A

  for docs-only / non-user-facing changes.

Definition of done

A PR is ready when:

• ✅ It does one thing.
• ✅ Tests cover the change.
• ✅ cargo test passes locally.
• ✅ ./script/clippy passes.
• ✅ License vetting passes (./script/check-licenses if you added/removed dependencies).
• ✅ For UI changes, screenshots or screen recordings are attached and visual regression tests are updated where relevant.
• ✅ The Release Notes: section is present.

What's in this section

• Development workflow — branching, building, running locally
• Testing — how the test suite is organised and run
• Debugging — local debugging, logs, crash investigation
• Patterns and conventions — coding style, error handling, GPUI patterns
• Tooling — clippy, cargo wrappers, scripts, release tooling