Source code
Revision control
Copy as Markdown
Other Tools
---
name: find-reviewer
description: Find the right reviewer for a Firefox/Gecko change so the user does not have to. Use this primarily when committing changes, to fill in the `r=` part of the commit message automatically instead of leaving it blank or guessing. Also use it when the user asks directly who should review a patch or what reviewer group to use.
allowed-tools:
- Bash(./mach file-info:*)
---
## NEVER invent a reviewer name
A reviewer or group name must be used **exactly** as it appears in the tooling's
output. NEVER abbreviate, shorten, guess, or make up a name (for example, writing
`r=#build` when the real group is `r=#firefox-build-system-reviewers`). `moz-phab`
rejects a submission containing an unknown reviewer (`#madeup-reviewer-group is
not a valid reviewer's name`), forcing the user to amend the commit and
re-submit. For a name that did not come straight from the Herald output, do not
use it unless it appears in `./mach file-info reviewer-groups`.
## Overview
When committing a Firefox/Gecko change, the `r=` reviewer should be filled in for
the user, not left to them. This skill determines it from the files the change
touches: the primary signal is the set of group reviewers that Phabricator's
Herald rules would automatically attach; when no rule matches, it falls back to
the individuals and groups that reviewed recent patches to those files.
Use it whenever you are about to write a commit message for a change, and also
when the user asks directly who should review something.
## Workflow
1. **Run the reviewer suggester** on a representative set of the changed files:
```
./mach file-info reviewers <file> [<file> ...]
```
2. **Interpret the output.**
- **Herald group reviewers** are the authoritative answer: these are the groups
Phabricator would add automatically, so prefer them. A group marked
`(blocking)` must approve before landing.
- When it prints **"No Herald group reviewers matched"**, it lists **recent
reviewers from version control history** instead. Treat these as candidates,
not certainties: rank by the counts shown, and discount groups that only
appear because of tree-wide mechanical commits (mass reformats, lint sweeps)
that are unrelated to the change.
- If neither yields a good answer, fall back to the file's Bugzilla component
(`./mach file-info bugzilla-component <file>`) and its matching reviewer
group, after validating the name (step 3).
3. **Validate names whose origin is not the Herald output.** Herald group
reviewers come straight from the current reviewer-selector data, so they are
already valid -- do not re-check them. Confirm the exact spelling only of a
group that came from somewhere else: one the user supplied, or one taken from
version control history (which may have been renamed or retired since that
commit landed):
```
./mach file-info reviewer-groups # one group name per line
```
Only use such a group if it appears in this list. (See the rule at the top.)
4. **Use it in the commit message.** Groups take a `#` prefix
(`r=#firefox-build-system-reviewers`); individuals take none (`r=somebody`).
Append `!` to require a reviewer's approval before landing
(`r=#firefox-build-system-reviewers!`); the command marks such reviewers
`(blocking)`. When the choice is ambiguous (several plausible groups, or only
noisy history), state the pick and the runners-up so the user can override.
## Notes
- This skill suggests reviewers; it does not submit anything to Phabricator.