| 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
-
Run the reviewer suggester on a representative set of the changed files:
./mach file-info reviewers <file> [<file> ...]
-
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).
-
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.)
-
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.
