RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://firefox-source-docs.mozilla.org/contributing/reviews.html below:

Getting reviews — Firefox Source Docs documentation

Thorough code reviews are one of Mozilla’s ways of ensuring code quality. Every patch must be reviewed by the module owner of the code, or one of their designated peers.

Commit message syntax

When submitting your commit(s), use the following syntax to request review for your patch:

Request

Syntax

Description

Single reviewer

r=reviewer

Request a review from a single reviewer (reviewer). Historically, the syntax r?reviewer requested a review, and r=reviewer marked the reviewer who accepted the patch before landing. Both can now be used interchangeably when requesting a review.

Multiple reviewers

r=reviewer1,reviewer2

Request reviews from both reviewer1 and reviewer2.

Blocking review

r=reviewer!

Request a blocking review from reviewer. This means that reviewer must review the patch before it can be landed.

Both optional and blocking reviews

r=reviewer1,reviewer2!

Request a blocking review from reviewer2, and an optional review from reviewer1.

Review groups

r=#review-group

Request a review from members of #review-group. A full list can be found below.

Blocking review groups

r=#review-group!

Request a blocking review from a review group. This will require at least one member of the group to approve before landing.

For example, the commit syntax to request review from group group-name or developer-nickname would be:

Bug xxxx - explain what you are doing and why r?#group-name

or

Bug xxxx - explain what you are doing and why r?developer-nickname

Reviews, and review groups, can be selected or adjusted after submission in the phabricator UI.

Sometimes when publishing a patch, groups will automatically be added as blocking reviewers due to the code being touched. In this case, you may want to check that the reviewers you requested review from are set to blocking as well.

Choosing reviewers

If you have a mentor assigned on the bug you are fixing, the mentor can usually either also review or find a suitable reviewer on your behalf.
If you do not have a mentor, see if your code fits into one of the review groups below, and request review from that group.
Otherwise, try looking at the history of the file to see who has modified it recently. (For example, hg log <modified-file> or git log <modified-file>)
Finally if you are still unable to identify someone, try asking in the #introduction channel on Matrix.

Getting attention

Generally most reviews will happen within roughly a week. If, however, a reviewer doesn’t respond within a week or so of the review request:

Contact the reviewer directly (either via e-mail or on Matrix).

Join developers on Mozilla’s Matrix server, and ask if anyone knows why a review may be delayed. Please link to the bug too.

If the review is still not addressed, mail the reviewer directly, asking if/when they’ll have time to review the patch, or might otherwise be able to review it.

Remember that reviewers are human too, and may have complex reasons that prevent them from reviewing your patch in a timely manner. Be confident in reaching out to your reviewer, but be mindful of the Mozilla Community Participation Guidelines while doing so.

For simple documentation changes, reviews are not required.

For more information about the review process, see the Code Review FAQ.

Review groups

Name

Owns

Members

#anchor-positioning-reviewers

Anchor positioning - related style and layout code