# Reviewing pull requests

Reviewing pull requestsAnyone can review a documentation pull request. Visit the pull requests section in the Kubernetes website repository to see open pull requests.Reviewing documentation pull requests is a great way to introduce yourself to the Kubernetes community. It helps you learn the code base and build trust with other contributors.Before reviewing, it's a good idea to:Read the content guide and style guide so you can leave informed comments.Understand the different roles and responsibilities in the Kubernetes documentation community.Before you beginBefore you start a review:Read the CNCF Code of Conduct and ensure that you abide by it at all times.Be polite, considerate, and helpful.Comment on positive aspects of PRs as well as changes.Be empathetic and mindful of how your review may be received.Assume good intent and ask clarifying questions.Experienced contributors, consider pairing with new contributors whose work requires extensive changes.Review processIn general, review pull requests for content and style in English. Figure 1 outlines the steps for the review process. The details for each step follow.flowchart LR subgraph fourth[Start review] direction TB S[ ] -.- M[add comments] --> N[review changes] N --> O[new contributors shouldchoose Comment] end subgraph third[Select PR] direction TB T[ ] -.- J[read descriptionand comments]--> K[preview changes inNetlify preview build] end A[Review open PR list]--> B[Filter open PRsby label] B --> third --> fourth classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,J,K,M,N,O grey class S,T spacewhite class third,fourth whiteJavaScript must be enabled to view this contentFigure 1. Review process steps.Go to https://github.com/kubernetes/website/pulls. You see a list of every open pull request against the Kubernetes website and docs.Filter the open PRs using one or all of the following labels:cncf-cla: yes (Recommended): PRs submitted by contributors who have not signed the CLA cannot be merged. See Sign the CLA for more information.language/en (Recommended): Filters for english language PRs only.size/<size>: filters for PRs of a certain size. If you're new, start with smaller PRs.Additionally, ensure the PR isn't marked as a work in progress. PRs using the work in progress label are not ready for review yet.Once you've selected a PR to review, understand the change by:Reading the PR description to understand the changes made, and read any linked issuesReading any comments by other reviewersClicking the Files changed tab to see the files and lines changedPreviewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the Conversation tab. Here's a screenshot (this shows GitHub's desktop site; if you're reviewing on a tablet or smartphone device, the GitHub web UI is slightly different):To open the preview, click on the Details link of the deploy/netlify line in the list of checks.Go to the Files changed tab to start your review.Click on the + symbol beside the line you want to comment on.Fill in any comments you have about the line and click either Add single comment (if you have only one comment to make) or Start a review (if you have multiple comments to make).When finished, click Review changes at the top of the page. Here, you can add a summary of your review (and leave some positive comments for the contributor!). Please always use the "Comment"Avoid clicking the "Request changes" button when finishing your review. If you want to block a PR from being merged before some further changes are made, you can leave a "/hold" comment. Mention why you are setting a hold, and optionally specify the conditions under which the hold can be removed by you or other reviewers.Avoid clicking the "Approve" button when finishing your review. Leaving a "/approve" comment is recommended most of the time.Reviewing checklistWhen reviewing, use the following as a starting point.Language and grammarAre there any obvious errors in language or grammar? Is there a better way to phrase something?Focus on the language and grammar of the parts of the page that the author is changing. Unless the author is clearly aiming to update the entire page, they have no obligation to fix every issue on the page.When a PR updates an existing page, you should focus on reviewing the parts of the page that are being updated. That changed content should be reviewed for technical and editorial correctness. If you find errors on the page that don't directly relate to what the PR author is attempting to address, then it should be treated as a separate issue (check that there isn't an existing issue about this first).Watch out for pull requests that move content. If an author renames a page or combines two pages, we (Kubernetes SIG Docs) usually avoid asking that author to fix every grammar or spelling nit that we could spot within that moved content.Are there any complicated or archaic words which could be replaced with a simpler word?Are there any words, terms or phrases in use which could be replaced with a non-discriminatory alternative?Does the word choice and its capitalization follow the style guide?Are there long sentences which could be shorter or less complex?Are there any long paragraphs which might work better as a list or table?ContentDoes similar content exist elsewhere on the Kubernetes site?Does the content excessively link to off-site, individual vendor or non-open source documentation?DocumentationSome checks to consider:Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken links as a result of this PR? Is there another option, like changing the page title without changing the slug?Does the PR introduce a new page? If so:Is the page using the right page content type and associated Hugo shortcodes?Does the page appear correctly in the section's side navigation (or at all)?Should the page appear on the Docs Home listing?Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code blocks, tables, notes and images.BlogEarly