michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: contribute: Extend Reviewer Expectations with additional rules

Browse source 
This change was triggered by a review comment linked below:
https://github.com/zephyrproject-rtos/zephyr/pull/83117#issuecomment-2549120181

It extends the current Reviewer Expectations with additional rules
agreed upon by multiple Zephyr contributors in order to simplify and
standardize the decision-making process during PR reviews.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit is contained in:
Carles Cufi 2024-12-18 10:13:48 +01:00 • committed by Benjamin Cabé
commit ea4e46d075
1 changed files with 19 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

21
doc/contribute/contributor_expectations.rst
View file

@ -368,10 +368,27 @@ Reviewer Expectations
they address all non-blocking comments. PR authors should acknowledge every
review comment in some way, even if it's just with an emoticon.
- Reviewers shall be *clear* and *concise* what changes they are requesting when the
- Style changes that the reviewer disagrees with but that are not documented as
part of the project can be pointed out as non-blocking, but cannot constitute
a reason for a request for changes. The reviewer can optionally correct any
potential inconsistencies in the tree, document the new guidelines or rules,
and then enforce them as part of the review.
- Whenever requesting style related changes, reviewers should be able to point
out the corresponding guideline, rule or rationale in the project's
documentation. This does not apply to certain types of requests for changes,
notably those specific to the changes being submitted (e.g. the use of a
particular data structure or the choice of locking primitives).
- Reviewers shall be *clear* about what changes they are requesting when the
"Request Changes" option is used. Requested changes shall be in the scope of
the PR in question and following the contribution and style guidelines of the
project.
project. Furthermore, reviewers must be able to point back to the exact issues
in the PR that triggered a request for changes.
- Reviewers should not request changes for issues which are automatically
caught by CI, as this causes the pull request to remain blocked even after CI
failures have been addressed and may unnecessarily delay it from being merged.
- Reviewers shall not close a PR due to technical or structural disagreement.
If requested changes cannot be resolved within the review process, the