diff --git a/docs/standards/review.md b/docs/standards/review.md
new file mode 100644
index 0000000000000000000000000000000000000000..73bab126850c677fb1ae2b08b6b76731b84c99cf
--- /dev/null
+++ b/docs/standards/review.md
@@ -0,0 +1,117 @@
+These review standards provide a name and description for common review tasks.
+
+## Usage
+
+When [reviewing a pull-request](/core/pr-review.md), you may consult this list for ideas/inspiration on things to check.  If you find a problem or feel that some QA task remains to
+be done, then it can help to post a link to the relevant guideline.  This practice allows newcomers to understand the critique, but it doesn't require you to
+write a long, bespoke blurb.
+
+!!! tip
+    The codes below (e.g. `r-jira`) are here to make it easier to reference these standards when chatting with others about PR review.
+
+## Common standards
+
+### JIRA {:#r-jira}
+
+_Standard code: `r-jira`_
+
+For most bug-fixes and improvements, there needs to be a [JIRA issue](/tools/issue-tracking.md#jira). However, [NFC](/tools/git.md#nfc) and [WIP](/tools/git.md#wip) PRs may not need an issue.
+
+### Test results {:#r-test}
+
+_Standard code: `r-test`_
+
+If the [automated tests](/testing/continuous-integration.md) come back with any failures, look into why. Hopefully, Jenkins provides an itemized list of failures. If not, dig further into the "Console" output for PHP-fatals or build-failures.
+
+### Code quality {:#r-code}
+
+_Standard code: `r-read`_
+
+Is it understandable? Does it follow common conventions? Does it fit in context? If it changes a difficult section of code -- does it tend to make that section better or worse?
+
+### Run it {:#r-run}
+
+_Standard code: `r-run`_
+
+Use the code somehow. You don’t need to attack every imaginable scenario in every PR, but you should do something to try it out. Be proportionate.
+
+### User impact {:#r-user}
+
+_Standard code: `r-users`_
+
+If a user was comfortable using the old revision, would they upgrade and assimilate naturally and unthinkingly to the new revision? If not, has there been commensurate effort to provide a fair transition-path and communication?
+
+### Technical impact {:#r-technical}
+
+_Standard code: `r-technical`_
+
+* Would the patch materially change the contract (signature/pre-condition/post-condition) for APIv3, a hook, a PHP function, a PHP class, a JS widget, or a CSS class?
+* Would you consider the changed element to be an officially supported contract? A de-facto important contract? An obscure internal detail?
+* How might the change affect other parts of `civicrm-core`? extensions? third-party integrations?
+* If it's hard to answer, look for inspiration:
+    * Grep `civicrm-core` or [universe](/tools/universe.md) to find out where the API/hook/function/etc is called. Consider how these might be affected.
+    * Look at the [Gotchas](#gotchas) for a list of issues that have been mistakenly overlooked in past reviews.
+* If there is a foreseeable problem:
+    * Is there a simple alternative?
+    * Has there been commensurate effort to communicate change and provide a fair transition path?
+
+### Maintainability {:#r-maint}
+
+_Standard code: `r-maint`_
+
+Many changes should introduce some kind of automated test or protective measure to ensure maintainability. However, there can be tricky cost/benefit issues, and the author and reviewer must exercise balanced judgment.
+
+### Documentation {:#r-doc}
+
+_Standard code: `r-doc`_
+
+Some changes require adding or updating documentation. Consider the impact of this change on users, system administrators, and developers. Do they need additional instructions in order to reap the benefits of this change? If so, [update documentation](/documentation/index.md) as necessary by making a corresponding PR on one of the guides.
+
+## Gotchas
+
+### Packaging {:#rg-pkg}
+
+_Standard code: `rg-pkg`_
+
+If the PR adds a new top-level file, new top-level folder, or novel file-type, consider whether "distmaker" will properly convey the file in `*.zip/*.tar.gz` builds.
+
+If the PR *removes* a dangerous file, then common package handling may not be enough to remove the file. (This is particularly for Joomla users, but also true for with
+manual file management on other platforms.) Consider updating `CRM_Utils_Check_Component_Security::checkFilesAreNotPresent`.
+
+### Permissions {:#rg-perm}
+
+_Standard code: `rg-perm`_
+
+If the PR changes the permissions model (by adding, removing, or repurposing a permission), are we sure that demo/test builds and existing installations will continue to work as expected?
+
+### Security {:#rg-sec}
+
+_Standard code: `rg-sec`_
+
+If the PR passes data between different tiers (such as SQL/PHP/HTML/CLI), is this data [escaped and validated](/security/index.md) correctly? Or would it be vulnerable to SQL-injections, cross-site scripting, or similar?
+
+### Settings {:#rg-setting}
+
+_Standard code: `rg-setting`_
+
+If the PR adds or removes a setting, will existing deployments or build-scripts which reference the setting continue to work as expected?
+
+### Upgrades {:#rg-upgrades}
+
+_Standard code: `rg-upgrades`_
+
+Some PRs change the database by modifying schema or inserting new data. Ensure new installations and upgraded installations will end up with consistent schema. (Extra: If it's a backport, take extra care to consider all upgrade paths.)
+
+If the upgrade adds a column or index, use a helper function to insert it. (This makes the upgrade more robust against alternative upgrade paths, such as backports/cherry-picks.)
+
+If the upgrade needs to populate or recompute data on a large table (such as `civicrm_contact`, `civicrm_activity`, or `civicrm_mailing_event_queue`), the upgrade screen could timeout. Consider applying the updates in batches.
+
+If the upgrade inserts new strings, should they be generated in a multilingual-friendly way?
+
+!!! seealso "See also: [Upgrade Reference](/framework/upgrade)"
+
+### Hook signature {:#rg-hook}
+
+_Standard code: `rg-hook`_
+
+Adding a new parameter to an existing hook may be syntactically safe, but is it semantically safe?
diff --git a/docs/tools/git.md b/docs/tools/git.md
index 3f5aaad5d5d5174c6ac4402146630d39394d9991..9c211f3df41668aebbb74645cdbff6c0006b4789 100644
--- a/docs/tools/git.md
+++ b/docs/tools/git.md
@@ -86,17 +86,21 @@ When filing a pull-request, use a descriptive subject. These are good examples:
 
 A few elements to include:
 
+ * **Acronyms** - Use zero or more of the [acronyms](#acronymns) below to flag your PR with certain characteristics.
  * **CRM-_XXXXX_** - This is a reference to the [Jira issue tracker](/tools/issue-tracking.md#jira). A bot will setup crosslinks between JIRA and GitHub.
  * **Description** - Provide a brief description of what the pull-request does.
- * **(WIP)** - "Work in Progress" - If you are still developing a set of
-   changes, it may be useful to submit a pull-request and flag it as
-   `(WIP)`. This allows you to have discussion with other developers and
-   check test results. Once the change is ready, update the subject line
-   to remove `(WIP)`.
- * **(NFC)** - "Non-Functional Change" - Most patches are designed to
-   change functionality (e.g. fix an error message or add a new button).
-   However, some changes are non-functional -- e.g. they cleanup the
-   code-style, improve the comments, or improve the test-suite.
+
+### Acronyms within PR subjects {:#acronymns}
+
+You can put these acronyms at the beginning of your PR subject to flag it as such.
+
+#### (WIP) - "Work in Progress" {:#wip}
+
+If you are still developing a set of changes, it may be useful to submit a pull-request and flag it as `(WIP)`. This allows you to have discussion with other developers and check test results. Once the change is ready, update the subject line to remove `(WIP)`.
+   
+#### (NFC) - "Non-Functional Change" {:#nfc}
+
+Most patches are designed to change functionality (e.g. fix an error message or add a new button). However, some changes are non-functional -- e.g. they cleanup the code-style, improve the comments, or improve the test-suite. 
 
 ### Pull request scope {:#pr-scope}
 
diff --git a/mkdocs.yml b/mkdocs.yml
index 9069b9a67080aa85e81eb8cf4645b89f6f16646f..9c79e84ac2cc49d5a1d4f6dba67a790507b901fc 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -234,11 +234,12 @@ pages:
     - Extending Smarty: framework/templates/extending-smarty.md
   - UI Reference: framework/ui.md
   - Upgrade Reference: framework/upgrade.md
-- Coding Standards:
+- Development Standards:
   - Coding Standards: standards/index.md
   - PHP Standards: standards/php.md
   - Javascript Reference: standards/javascript.md
   - Database Standards: standards/database.md
+  - Review Standards: standards/review.md
 - Documentation:
   - Writing Documentation: documentation/index.md
   - Documenting Extensions: documentation/extensions.md