How to contribute

This wiki section is for working in the wgpu codebase: getting changes merged, navigating the test taxonomy, and matching the project's conventions. The authoritative source is CONTRIBUTING.md at the repo root, with extra rules in AGENTS.md and docs/review-checklist.md. This page summarizes them so you can find the right reference quickly.

Active contributors: Andy Leiserson, Erich Gubler, Connor Fitzgerald, teoxoy, Jim Blandy, Kevin Reid

The short version

1. Drop in to Matrix (#wgpu:matrix.org) or the Rust GameDev Discord #wgpu to validate large or opinionated changes before you build them. Maintainers explicitly call out that big, complex pull requests are risky and likely to be rejected unless pre-discussed.
2. Read CONTRIBUTING.md, GOVERNANCE.md, CODE_OF_CONDUCT.md, and the relevant docs/*-checklist.md.
3. Set up your environment as in Getting started.
4. Write code that matches the existing style. See patterns-and-conventions.md.
5. Add or update tests. See testing.md.
6. Update CHANGELOG.md for user-visible changes (see xtask/src/changelog.rs).
7. Open a draft PR if you want feedback, or a real PR if you're ready for review. The review checklist is docs/review-checklist.md.

Sub-pages

• Development workflow — how a change moves from a local branch to a merged PR.
• Testing — every test crate in the repo, what it covers, and how to run it.
• Debugging — environment variables, logging, validation layers, RenderDoc, traces, the player crate.
• Patterns and conventions — coding patterns you'll see in source files.
• Tooling — xtask, formatters, linters, CI, and bot-driven workflows.

What gets reviewed

docs/review-checklist.md is short and worth reading in full. Reviewers look for:

• Clear, single-purpose change. The project explicitly avoids large, complex PRs (CONTRIBUTING.md).
• Tests that exercise the new behavior.
• Validation errors that match the spec, not the CTS. AGENTS.md is firm about this: the CTS expecting a behavior doesn't make it correct; the WebGPU/WGSL spec is the source of truth.
• Lock-rank discipline maintained (wgpu-core/src/lock/).
• No new unsafe in naga (#![forbid(unsafe_code)]) and no new std:: imports in no_std crates.
• Changelog entry where appropriate.

Cadence and meetings

• Triage and planning happen weekly on Wednesday at 11:00 US Eastern Time on Google Meet. Public; see CONTRIBUTING.md for the link.
• Releases happen roughly every three months as breaking versions. The release process is in docs/release-checklist.md.

A note on AI

CONTRIBUTING.md allows LLM-assisted code, but the author is fully responsible for the change and must understand and justify it. "LLM generated" is not a reason to accept lower-quality code. The undue-burden rule applies: maintainers may close PRs that demand disproportionate review effort.