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:
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.
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, 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.
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 will be needed.
[hotfix] pull requests, consensus needs to be checked in the pull request.
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
If the pull request needs specific attention, one of the tagged committers/contributors should give the final approval.
In this step, we check if a contribution folllows the agreed upon approach from the previous discussion in Jira or the mailing lists.
This question should be answerable from the Pull Request description (or the linked Jira) as much as possible.
We recommend to check this before diving into the details of commenting on individual parts of the change.
This is the detailed code review of the actual changes, covering:
Code guidelines can be found in the Flink Code Style and Quality Guide.
If the pull request introduces a new feature, the feature should be documented. The Flink community is maintaining both an English and a Chinese documentation. So both documentations should be updated. If you are not familiar with the Chinese language, please open a Jira assigned to the
chinese-translation component for Chinese documentation translation and link it with current Jira issue. If you are familiar with Chinese language, you are encouraged to update both sides in one pull request.
See more about how to contribute documentation.