> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superoffice.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How to request a review

> How to request a review before merging a contribution to main

How to initiate the review process depends on where you updated the content.

## Edited single file in browser

If you followed the instructions to [edit a file on GitHub][1], you've already created the pull request.

Wait for a notification from the reviewer. Then [view and incorporate feedback on the pull request][5].

## Worked on a local branch

* If you worked on a branch from a [clone][2], go directly to [the public docs repo][4].
* If you worked on a [fork][3], go to your **forked GitHub repo** on GitHub.com instead.

1. Go to the repo on GitHub.com. GitHub should detect the updated code and prompt you to make a pull request.

2. Click the **Compare and create pull request** button.

   It might also look like this:

   ![Open PR on GitHub -screenshot][img10]

3. Fill in info such as title and description and select a reviewer.

   In the description or comments section be sure to include the text "Resolves `#[INSERT ISSUE NUMBER HERE]`" where your previously created issue number is associated with this pull request.

   ![Create PR on GitHub -screenshot][img11]

[img10]: /media/loc/en/contribute/github-open-pr.png

[img11]: /media/loc/en/contribute/github-create-pr.png

<Note>
  There are extensions for creating PRs directly from VS Code, however, authentication (especially with enterprise accounts) is not trivial. Creating PRs on GitHub is strongly recommended.
</Note>

## What happens now?

* Follow the discussion in the **Conversation** tab.
* Look for GitHub notifications on the PR and be prepared to [implement the requested changes][5] (if any).
* A preview link normally appears automatically as a bot comment within moments of your push. If you worked from a fork, it will not - see [Manual (custom) previews][6] to request one, and batch your changes into a **draft** PR first rather than requesting a fresh preview after every small fix.

[1]: ../overview#editing-in-github

[2]: ../getting-started#set-up-the-repository-locally

[3]: ../how-to-edit-an-article#how-to-edit-and-preview-content

[4]: https://github.com/SuperOfficeDocs/docs

[5]: ./incorporate-feedback

[6]: ../deployment#manual-previews