From ea4e46d075497ace559893ba5f644dc48fb27696 Mon Sep 17 00:00:00 2001 From: Carles Cufi Date: Wed, 18 Dec 2024 10:13:48 +0100 Subject: [PATCH] doc: contribute: Extend Reviewer Expectations with additional rules 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 Signed-off-by: Anas Nashif --- doc/contribute/contributor_expectations.rst | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/doc/contribute/contributor_expectations.rst b/doc/contribute/contributor_expectations.rst index 2f182afae3f..1e33d3ceaa1 100644 --- a/doc/contribute/contributor_expectations.rst +++ b/doc/contribute/contributor_expectations.rst @@ -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