docs: include pull request review checklist (#5094)

Co-authored-by: Amir Zarrinkafsh <nightah@me.com>

docs/content/en/contributing/guidelines/introduction.md

@@ -24,14 +24,6 @@ sense to follow one just let us know your reasoning when you make a PR if it's n
 
 Some general guidelines include:
 
-- Testing:
-  - While we aim for 100% coverage on changes, we do not enforce this where it doesn't make practical sense:
-    - A test which just marks a line as tested is not necessarily an effectual test
-    - Sometimes there is limited ways in which tests can be performed and the limitation makes the test ineffectual
-  - Tests should be named to reflect what they testing for and which part of the code they are testing
-  - It's strongly encouraged for bug fixes that contributors create a test that fails prior to fixing the bug and passes
-    after fixing the bug and that this test is part of the contribution
-  - It's strongly encouraged for features that contributors create have as much testing as is reasonable
 - It's recommended people wishing to contribute discuss their intended changes prior to contributing
   - This helps avoid people doubling up on contributions
   - This helps avoid conflicts between contributions

docs/content/en/contributing/guidelines/pull-request.md

@@ -31,3 +31,32 @@ the [master] branch.
 
 Every [Pull Request] will undergo a formal review process. This process is heavily complicated if you rewrite history
 and/or perform a force push, especially after a maintainer has started a review. As such we request that any action that
+you merge `origin/master` into your branch to synchronize your commit after the initial review and any other action that
+rewrites history.
+
+### Requirements
+
+The following requirements must be met for a pull request to be accepted. This list also acts as a checklist for
+maintainers in their review process.
+
+- The changes must be [documented](../prologue/documentation-contributions.md) if they add or change behaviour
+- The changes must meet the following guidelines:
+  - [General](introduction.md#general-guidelines)
+  - [Commit Message](commit-message.md)
+  - [Database Schema](database-schema.md)
+  - [Documentation](documentation.md)
+  - [Testing](testing.md)
+  - [Accessibility](accessibiliy.md)
+  - [Style](style.md)
+- The changes adhere to all of the relevant linting and quality testing automations
+- The pull request closes related issues by mentioning them appropriately
+- The contribution adhere to the security by design principles by:
+  - Setting secure defaults
+  - Disallows critically insecure settings
+  - Requires explicit awareness by users that specific settings may reduce security
+- Potential future items:
+  - Contribution includes DCO
+  - Contribution includes REUSE-compliance requirements
+
+[Pull Request]: https://github.com/authelia/authelia/pulls
+[master]: https://github.com/authelia/authelia/tree/master/

docs/content/en/contributing/guidelines/testing.md

@@ -0,0 +1,27 @@
+---
+title: "Testing"
+description: "Authelia Development Testing Guidelines"
+lead: "This section covers the testing guidelines."
+date: 2022-06-15T17:51:47+10:00
+draft: false
+images: []
+menu:
+  contributing:
+    parent: "guidelines"
+weight: 320
+toc: true
+---
+
+The following outlines the specific requirements we have for testing the Authelia code contributions.
+
+- While we aim for 100% coverage on changes and additions, we do not enforce this where it doesn't make practical sense:
+  - A test which just marks a line as tested is not necessarily an effectual test
+  - Sometimes there is limited ways in which tests can be performed and the limitation makes the test ineffectual
+- Tests should be named to reflect what they testing for and which part of the code they are testing
+- It's required for bug fixes that contributors create a test that fails prior to and passes
+  subsequent to the fix being applied, this test must be included in the contribution, excluding this test will likely
+  result in the fix being rejected unless explicitly agreed and advised otherwise by the
+  [core team](../../information/about.md#core-team)
+- It's strongly encouraged for features that contributors create have as much testing as is reasonable i.e. any line
+  that can be tested should be tested, if the line can't be tested generally this is an indication a refactor may be
+  required