# PR Review Checklist Below is a checklist for reviewing Kuberentes pull requests. This is not meant to cover all aspects of reviewing a PR, but to serve as ideas for things to check. - [ ] If a new file is added, make sure it has the Kubernetes license boilerplate comment at the top of the file, and that the year is the current year. There is no need to update the year on existing files that are changed. - [ ] Check imports (standard libraries, third party, k8s) - they should be grouped and sorted. First group are standard libraries, second group are third party libraries, and third group at k8s libraries. - [ ] Check variable/function names for naming convention. For example, Kubernetes prefers abbreviations to be all upper-case, so "YAML" not "Yaml" and "ID" not "Id". - [ ] Are there any security concerns? - [ ] Are there any backward compatibility concerns? Kubectl's version skew policy is for it to be compatible with +/- 1 minor version of the server. - [ ] Check the scope of types and functions. Is something public that does not need to be? - [ ] Do you know of a better way to do something? The Kubernetes codebase is large and sometimes a developer may not be aware of something similar that was done elsewhere in the code. In this case, point the developer to an example where it is done differently and see if it might be helpful in this PR's case. - [ ] Are things being done consistently with existing Kubernetes code? Sometimes it is better to remain consistent rather than deviate from the way that things are done everywhere else in the code. Be flexible to improvements, but question significant deviations. An exception would be when an intentional deviation is being made to improve the code and is what will eventually become a new pattern. - [ ] Are there unit tests? All new code should have unit tests. Changes to existing code should add any missing unit tests if possible. - [ ] Are there integration tests needed for this change? Do existing integration tests need to be updated? - [ ] Are there e2e tests needed for this change? Do existing e2e tests need to be updated? - [ ] Did the PR author include a release note describing a user-facing change? If no release note, then it should be "NONE" in the release note placeholder of the PR description. - [ ] Did the PR author properly link a GitHub issue to the PR? Issues can be auto-closed if the text `Fixes #1234` is used (will close k/k issue 1234) or `Fixes <kubectl issue url>` (will close kubectl issue linked by the URL). It is possible for a PR to not have an issue, but if there is one, it should be linked for tracking purposes. - [ ] Did the PR author follow the Kubernetes PR template? If not, consider asking them to update the PR to follow the template. This will help reviewers to understand and review the PR more effectively. - [ ] Are there any user-facing error messages written by the code in this PR? And if so, do they follow the [standard convention of lower case and no ending punctuation](https://github.com/golang/go/wiki/CodeReviewComments#error-strings)? Does the error message make sense and provide a unique enough context for a user to troubleshoot the reason for the error? - [ ] Are there any spelling, grammar, or other naming mistakes? If so, gently request a change. You can prefix your suggestion with "nit" to acknowledge that it is a nit-pick change. For example: "nit: discovrey should be discovery" - [ ] Is the proposed change something that is wanted by the SIG? If there is an issue associated with the PR, has the issue been triaged/accepted, or has it not been discussed yet? Is the change consistent with the direction communicated in SIG meetings, KEPs, or other discussions that have taken place? If unclear, then consider bringing it up on Slack and/or as a topic at the next SIG meeting.