snuyanzin commented on code in PR #597:
URL: https://github.com/apache/flink-web/pull/597#discussion_r1114203993


##########
docs/content/how-to-contribute/reviewing-prs.md:
##########
@@ -0,0 +1,89 @@
+---
+title: Review Pull Requests
+bookCollapseSection: false
+weight: 18
+---
+
+# How to Review a Pull Request
+
+This guide is for all committers and contributors that want to help with 
reviewing code contributions. Thank you for your effort - good reviews are one 
of the most important and crucial parts of an open source project. This guide 
should help the community to make reviews such that:
+
+* Contributors have a good contribution experience.
+* Our reviews are structured and check all important aspects of a contribution.
+* We make sure to keep a high code quality in Flink.
+* We avoid situations where contributors and reviewers spend a lot of time 
refining a contribution that gets rejected later.
+
+## Review Checklist
+
+Every review needs to check the following six aspects. **We encourage to check 
these aspects in order, to avoid spending time on detailed code quality reviews 
when formal requirements are not met or there is no consensus in the community 
to accept the change.**
+
+### 1. Is the Contribution Well-Described?
+
+Check whether the contribution is sufficiently well-described to support a 
good review. Trivial changes and fixes do not need a long description. If the 
implementation is exactly [according to a prior discussion on Jira or the 
development mainling list]({{< relref "how-to-contribute/contribute-code" 
>}}#consensus), only a short reference to that discussion is needed.
+If the implementation is different from the agreed approach in the consensus 
discussion, a detailed description of the implementation is required for any 
further review of the contribution.
+
+Any pull request that changes functionality or behavior needs to describe the 
big picture of these changes, so that reviews know what to look for (and don’t 
have to dig through the code to hopefully understand what the change does).
+
+
+**A contribution is well-described if the following questions 2, 3, and 4 can 
be answered without looking at the code.**
+
+-----
+
+### 2. Is There Consensus that the Change or Feature Should Go into Flink?
+
+This question can be directly answered from the linked Jira issue. For pull 
requests that are created without prior consensus, a [discussion in Jira to 
seek consensus]({{< relref "how-to-contribute/contribute-code" >}}) will be 
needed.
+
+
+For `[hotfix]` pull requests, consensus needs to be checked in the pull 
request.
+
+
+-----
+
+### 3. Does the Contribution Need Attention from some Specific Committers and 
Is There Time Commitment from These Committers?
+
+Some changes require attention and approval from specific committers. For 
example, changes in parts that are either very performance sensitive, or have a 
critical impact on distributed coordination and fault tolerance need input by a 
committer that is deeply familiar with the component.
+
+As a rule of thumb, special attention is required when the Pull Request 
description answers one of the questions in the template section “Does this 
pull request potentially affect one of the following parts” with ‘yes’.
+
+This question can be answered with
+
+* *Does not need specific attention*
+* *Needs specific attention for X (X can be for example checkpointing, 
jobmanager, etc.).*
+* *Has specific attention for X by @committerA, @contributorB*
+
+**If the pull request needs specific attention, one of the tagged 
committers/contributors should give the final approval.**
+
+----
+
+### 4. Does the Implementation Follow the Agreed Upon Overall 
Approach/Architecture?
+
+In this step, we check if a contribution folllows the agreed upon approach 
from the previous discussion in Jira or the mailing lists.

Review Comment:
   ```suggestion
   In this step, we check if a contribution follows the agreed upon approach 
from the previous discussion in Jira or the mailing lists.
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to