From 2c7bb0ba7f3e6f5c406f34665f49c46be695ac4e Mon Sep 17 00:00:00 2001 From: ahuston-0 Date: Sun, 11 Feb 2024 15:13:29 -0500 Subject: [PATCH] Add additional info for critical issues and the review process Signed-off-by: ahuston-0 --- docs/CONTRIBUTING.md | 55 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 10ab27d..4299051 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -46,6 +46,61 @@ but I cannot be bothered rn | exp/\ | \ is a non-critical experiment. This is used for shipping around potential new features or fixes to multiple branches | | merge/\ | \ 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