New story in the user guide. Target is the `main` branch of che-docs but it's expected to be published as a "minimalistic" Che blog article first (in AsciiDoc, using the same variables used in Che documentation and the same Vale rules).

Che helps reviewing GitHub pull requests. This article should explain:

How a reviewer of a GitHub pull request can benefit of using Che

• Click the Che link on a comment or in the PR status details to git clone the PR branch in a cloud development environment
• Inspect the PR changes from Theia (the default IDE)
• Run a linter, run the build, run unit tests
• Run the application to verify the problem is solved
• (optional) run another workspace on the main branch and reproduce the problem
• Approve the PR from the IDE

—
Scoping:

• The important feature is: "After clicking on a link, you have a complete running environment where you can Run a linter, run the build, run unit tests", rather than "Use the IDE extension for your Git provider to approve the PR from the IDE"
• For upstream, GitHub public repositories occupy most of the scenery. For downstream, Git provider are more diverse (Bitbucket, GitHub, GitLab), and most likely to be private. To write docs that apply everywhere, and keep them minimal, it could be safe to decide to throw away the "approve the PR from the IDE" step, or make it an alternative to a default step "use the Web UI of your Git provider to comment or merge the merge or pull request". The precedent steps can be written to be Git provider agnostic.
• To start the workspace in the best conditions, you should create a workspace from the feature branch. Else, if you start the workspace from the main branch and switch to the feature branch only later, and if the feature branch has changes in the devfile, you would be unable to test the changes in the devfile. Therefore, the first steps in the blog post are dot advisable.