How to contribute

The LLVM project has been a community of practice for two decades. This page describes the practical loop a new contributor goes through to get a change reviewed and merged into main. It is a condensed companion to the canonical guides:

• LLVM Developer Policy
• Contributing to LLVM
• GitHub workflow
• CONTRIBUTING.md (in this repo)

If those guides disagree with this page, the canonical guides win.

The loop in one paragraph

You fork the repo on GitHub, clone your fork, create a branch, make changes, run the relevant check-* test suites locally, push your branch, open a pull request against main, and wait for a maintainer to review. Most non-trivial PRs see a few rounds of review feedback. When approved, the PR can be merged via "Squash and merge" or via a cherry-picked landing depending on the area's convention. Releases are cut from main every six months on a published schedule.

What goes where

You want to ...	Look here
Pick up a "good first issue"	GitHub issues filtered by label good first issue
Discuss a design before writing code	LLVM Discourse — pick the category for the affected subproject
Find the maintainer of an area	The per-subproject Maintainers.md (e.g. llvm/Maintainers.md, clang/Maintainers.md). See maintainers.
Get real-time help	LLVM Discord
Read a change log	LLVM release notes

What "approved" looks like

• For most subprojects a single LGTM ("Looks Good To Me") from a maintainer is enough. Some sub-areas require two reviewers; check the area's culture.
• Trivial changes (typo fixes, comment-only edits, obvious build fixes) can be landed as "post-commit review" — push directly and respond to follow-up comments. Do this only if you are sure.
• Reverts of recently-landed commits don't need pre-commit approval if they are restoring the tree to a green state.

Definition of done

A change is ready to merge when:

1. It builds cleanly (no new warnings) on the affected subprojects.
2. The relevant check-<subproject> lit tests pass locally.
3. New behavior has accompanying regression tests under the appropriate test/ directory.
4. Public-API changes are reflected in the subproject's release notes (e.g., llvm/docs/ReleaseNotes.md, clang/docs/ReleaseNotes.rst).
5. The PR description follows the project's commit-message conventions (subject prefixed with the area, e.g., [InstCombine] ... or [clang][CodeGen] ...).
6. CI is green (or any failures have been clearly explained as unrelated).

Sub-pages

• Development workflow — branch, code, test, PR, merge
• Testing — the lit and unit-test layers
• Debugging — common failure modes and how to investigate them
• Patterns and conventions — coding style, error handling, naming
• Tooling — the build system, code generators, and helper scripts