diff options
Diffstat (limited to 'docs/contributing/reviews.rst')
| -rw-r--r-- | docs/contributing/reviews.rst | 53 |
1 files changed, 49 insertions, 4 deletions
diff --git a/docs/contributing/reviews.rst b/docs/contributing/reviews.rst index 386872819c..8f026eec85 100644 --- a/docs/contributing/reviews.rst +++ b/docs/contributing/reviews.rst @@ -5,10 +5,37 @@ Getting reviews 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. -To request a review, you will need to specify a review group (starts with #). If there is not, you should select one or more usernames either when you submit the patch, or afterward in the UI. -If you have a mentor, the mentor can usually either also review or find a suitable reviewer on your behalf. +Commit message syntax +--------------------- -For example, the syntax to request review from a group should be: +When submitting your commit(s), use the following syntax to request review for your patch: + +.. list-table:: + :header-rows: 1 + + * - 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: .. code-block:: @@ -18,12 +45,30 @@ For example, the syntax to request review from a group should be: Bug xxxx - explain what you are doing and why r?developer-nickname -Getting attention: If a reviewer doesn't respond within a week, or so of the review request: +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 <https://chat.mozilla.org/#/room/#introduction:mozilla.org>`_. + + +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 <https://chat.mozilla.org>`_, 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 <https://www.mozilla.org/en-US/about/governance/policies/participation/>`_ while doing so. + For simple documentation changes, reviews are not required. For more information about the review process, see the :ref:`Code Review FAQ`. |