Add additional info for critical issues and the review process

Signed-off-by: ahuston-0 <aliceghuston@gmail.com>

docs/CONTRIBUTING.md

@@ -46,6 +46,61 @@ but I cannot be bothered rn
 | exp/\<item\>     | \<item\> is a non-critical experiment. This is used for shipping around potential new features or fixes to multiple branches                                                         |
 | merge/\<item\>   | \<item\> is a temporary branch and should never be merged directly to main. This is solely used for addressing merge conflicts which are too complex to be merged directly on branch |
 
+### Review Process
+
+For PR's that impact personal files (personal SOPS files, SSH keys, your laptops,
+your servers), those can be added with one approval and will eventually be
+auto-approved. However, for PR's affecting global files you need two
+approvals based on the latest commit (stale approvals will not work).
+
+In the event that quorum cannot be reached on approvals (specifically members
+that cannot approve who normally would), the PR will be placed on-hold unless
+a member who is unable to approve defers their approval power. This deferral
+must be publicly acknowledged in the PR and confirmed by another member.
+This process essentially acknowledges that at least two people besides the
+author are aware of the PR, however the third is deferring their approval powers
+to those already involved.
+
+This quorum rule can only be overrided for critical items (branches beginning
+in `hotfix/` or `urgent/`), but an additional reviewer must be tagged regardless
+and the assignee must assert that the PR has been tested on at least one
+machine. Please see [Critical Issues](#critical-issues) for further details.
+
+### Nix Project
+
+All issues must be tagged to the `Nix Flake Features` project, and any PR's
+which do not have an associated issue must be tagged to the same. It is
+**highly recommended** that all PR's be tagged to an issue but PR's should
+not be rejected if they are not tagged to an issue.
+
+Any issue or PR that is tagged to the project must have a priority (High/Medium
+/Low) and an estimate (rough amount of time in hours) associated. Start date
+and end date must be included for non-critical items (branches not beginning
+with `hotfix/` or `urgent/`). This is done in order to understand effort and
+criticality of the project item. Please see [Critical Issues](#critical-issues)
+for further details.
+
+### Critical Issues
+
+As previously described, a critical issue is one which has a branch associated
+with it beginning with `urgent/` or `hotfix/`. Any reviewer who is going to
+review one of these PR's must assert that they have read and understood these
+rules.
+
+#### Implications
+
+- Critical issues may bypass the [quorum rules](#review-process), as long as the
+  PR has been tested on at least one machine
+  - Issues which bypass the quorum process must have a second reviewer tagged
+  - All critical issues which bypass the approval process must have an RCA issue
+    opened and the RCA logged into the `inc/` folder
+  - The second reviewer has 2 weeks to retroactively review and approve the PR
+  - If the retro does not happen in the given window, an issue shall be opened
+    to either re-review the PR or to revert and replace the fix with a 
+    permanent solution
+- Critical issues must be tagged to `Nix Flake Features` project, and must have
+  a priority of `High` and an estimate tagged. Start and end date are not needed
+
 ## Secrets
 
 We allow secrets to be embedded in the repository using `sops-nix`. As part of