1.. _reviewer-expectations:
2
3Reviewer Expectations
4#####################
5
6- Be respectful when commenting on PRs. Refer to the Zephyr `Code of Conduct`_
7  for more details.
8
9- The Zephyr Project recognizes that reviewers and maintainers have limited
10  bandwidth. As a reviewer, prioritize review requests in the following order:
11
12    #. PRs related to items in the `Zephyr Release Plan`_ or those targeting
13       the next release during the stabilization period (after RC1).
14    #. PRs where the reviewer has requested blocking changes.
15    #. PRs assigned to the reviewer as the area maintainer.
16    #. All other PRs.
17
18- Reviewers shall strive to advance the PR to a mergeable state with their
19  feedback and engagement with the PR author.
20
21- Try to provide feedback on the entire PR in one shot. This provides the
22  contributor an opportunity to address all comments in the next PR update.
23
24- Partial reviews are permitted, but the reviewer must add a comment indicating
25  what portion of the PR they reviewed. Examples of useful partial reviews
26  include:
27
28  - Domain specific reviews (e.g. Devicetree).
29  - Code style changes that impact the readability of the PR.
30  - Reviewing commits separately when the requested changes cascade into the
31    later commits.
32
33- Avoid increasing scope of the PR by requesting new features, especially when
34  there is a corresponding :ref:`RFC <rfcs>` associated with the PR. Instead,
35  reviewers should add suggestions as a comment to the :ref:`RFC <rfcs>`. This
36  also encourages more collaboration as it is easier for multiple contributors
37  to work on a feature once the minimum implementation has merged.
38
39- When using the "Request Changes" option, mark trivial, non-functional,
40  requests as "Non-blocking" in the comment. Reviewers should approve PRs once
41  only non-blocking changes remain. The PR author has discretion as to whether
42  they address all non-blocking comments. PR authors should acknowledge every
43  review comment in some way, even if it's just with an emoticon.
44
45- Style changes that the reviewer disagrees with but that are not documented as
46  part of the project can be pointed out as non-blocking, but cannot constitute
47  a reason for a request for changes. The reviewer can optionally correct any
48  potential inconsistencies in the tree, document the new guidelines or rules,
49  and then enforce them as part of the review.
50
51- Whenever requesting style related changes, reviewers should be able to point
52  out the corresponding guideline, rule or rationale in the project's
53  documentation.  This does not apply to certain types of requests for changes,
54  notably those specific to the changes being submitted (e.g. the use of a
55  particular data structure or the choice of locking primitives).
56
57- Reviewers shall be *clear* about what changes they are requesting when the
58  "Request Changes" option is used. Requested changes shall be in the scope of
59  the PR in question and following the contribution and style guidelines of the
60  project. Furthermore, reviewers must be able to point back to the exact issues
61  in the PR that triggered a request for changes.
62
63- Reviewers should not request changes for issues which are automatically
64  caught by CI, as this causes the pull request to remain blocked even after CI
65  failures have been addressed and may unnecessarily delay it from being merged.
66
67- Reviewers shall not close a PR due to technical or structural disagreement.
68  If requested changes cannot be resolved within the review process, the
69  :ref:`pr_technical_escalation` path shall be used for any potential resolution
70  path, which may include closing the PR.
71
72.. _Code of Conduct: https://github.com/zephyrproject-rtos/zephyr/blob/main/CODE_OF_CONDUCT.md
73
74.. _Zephyr Release Plan: https://github.com/orgs/zephyrproject-rtos/projects/13
75