From 47fe00c14eb57b1c736db63bc45c3a2b9902e641 Mon Sep 17 00:00:00 2001
From: nate contino <nathan.contino@mongodb.com>
Date: Thu, 25 Feb 2021 13:21:41 -0700
Subject: [PATCH] (DOCSP-14316): Review Guidelines for docs-realm (#826)

---
 .github/pull_request_template.md |  3 ++
 REVIEWING.md                     | 59 ++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+)
 create mode 100644 REVIEWING.md

diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 09a760862c..d4db51b94b 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -8,3 +8,6 @@ https://docs-mongodborg-staging.corp.mongodb.com/NNNNNNN/java/docsworker-xlarge/
 
 ### Docs staging build link:
 https://workerpool-boxgs.mongodbstitch.com/pages/job.html?jobId=NNNNNNNNNNNNNNNNNNNNNN
+
+### Review Guidelines
+[REVIEWING.md](REVIEWING.md)
diff --git a/REVIEWING.md b/REVIEWING.md
new file mode 100644
index 0000000000..033bc2faf0
--- /dev/null
+++ b/REVIEWING.md
@@ -0,0 +1,59 @@
+# Reviewing Guidelines for the MongoDB Realm Documentation
+
+Realm Docs contributions typically go through two sets of reviewers:
+
+1. A **copy edit**, which focuses on structure and wording
+2. A **technical review**, which addresses code snippets and the
+   technical correctness of prose.
+
+## Technical Review
+
+Review the technical accuracy and completeness of a docs PR
+(Pull Request) and correct it if necessary.
+
+### What to Review
+
+- Code snippets
+- Technical claims, e.g. ("To create a `Foo`, use the `Bar.createFoo()` method")
+- Missing "footguns", i.e. potential pitfalls that could trip up users
+  who try to follow the documentation.
+
+### What Not to Review
+
+- Wording of sentences: while suggestions are appreciated, PRs
+  that have reached the technical review stage have already passed copy
+  editing. Copy edits are out of scope of technical reviews, unless they
+  directly relate to a technical claim.
+- Structure of the page: as with wording, structural changes are out of
+  scope and should never block approval of a technical review.
+- Any lines of the page that have not been touched in the PR,
+  unless they refer to content that has changed as a result of the PR or
+  fall within the scope of the PR's related JIRA ticket. If you do notice
+  an issue with content that's outside of the JIRA ticket's scope,
+  please mention it in the #docs-realm Slack channel or file a JIRA
+  ticket with the `DOCSP` project.
+
+## Copy Edits
+
+Review the structure, wording and flow of a docs PR and correct it if
+necessary.
+
+### What to Review
+
+- Wording
+- Page structure
+- Snooty Autobuilder build errors and warnings
+- Altered or added example app tests (if any have changed, CI should
+  automatically run)
+- Technical content from a "looks correct" perspective, since technical
+  review should address deeper concerns
+- Whether or not the PR fulfills the Acceptance Criteria described in the
+  linked JIRA ticket.
+
+### What Not to Review
+
+Very little is completely off-limits to a copy edit of a PR -- if you
+notice a technical issue, it's best to call it out early.
+However,
+copy editors should constrain their reviews to only content within the
+scope of the JIRA ticket.