> ## 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.

# Reviews on SuperOfficeDocs

> Explanation of how to request a review, to handle feedback and suggested changes, and to review someone else's contributions on SuperOfficeDocs.

Reviews can be many things. This article focuses on the required steps to get a proposed change accepted and published to `docs.superoffice.com`.

The main objectives of our mandatory pull request (PR) reviews and automatic tests are to ensure that content is easy to find, easy to understand, and easy to use and that changes don't cause the build pipeline to fail or the site to break.

## I'm a contributor, translator, or content author

To incorporate your proposed changes, we'll merge your pull request (PR) with the main branch after approving the PR.

1. [Create the PR (request a review)][1]. This signals that you consider your work done.

   <Note>
     If you want intermittent input from a co-author or a subject matter expert (SME) before you're done, contact them directly or @ mention them in a comment on the GitHub issue.
   </Note>

2. When you receive GitHub notifications on the PR, study the comments and [incorporate the feedback][5].

   It is not uncommon for this step to involve several discussions and fixes.

## I'm a reviewer

As a reviewer, you'll do one or more of the following tasks:

* Comment on the changes proposed in PR.
* Approve the changes.
* Request further changes (blocks merge).

[How to comment or start a review][4]

## Merge requirements

A PR into `main` needs at least 1 approving review from a Code Owner before it can merge. [`.github/CODEOWNERS`][6] currently lists a single owner for the whole repo, so every PR - including translations and small fixes - needs that owner's approval.

<Note>
  GitHub blocks self-approval of your own PR at the API level, so the Code Owner can't satisfy this requirement on their own PRs. See [the branch strategy page][7] for the rest of the branch protection restrictions that apply here, and how the Code Owner's own PRs get merged in the meantime.
</Note>

## What to check

* [Markdown formatting][3] - no linting errors
* [Style guide][2]
* Automatic tests should pass - see [Automated tests][9] for the full list (markdownlint, Vale, broken-link checks) and where to read their results. Markdownlint and Vale are advisory only for now: a flagged issue is worth a look, but it does not block the merge on its own.
* The [Mintlify preview deployment][8] should build successfully, and the changed pages should look correct in it.
* Reference to deleted pages should be removed from toc and other content.
* Reference to moved or renamed pages should be updated so no links break.
* Images and other resources used only in a deleted file should also be deleted.

[1]: ./request-review

[2]: ../style-guide/index

[3]: ../markdown-guide/index

[4]: ./check-changes

[5]: ./incorporate-feedback

[6]: https://github.com/SuperOfficeDocs/docs/blob/main/.github/CODEOWNERS

[7]: ../branch-strategy

[8]: ./check-changes#preview

[9]: ../automated-tests