From 4222e4d817d90c3382d3a0ef49a4305100d1857e Mon Sep 17 00:00:00 2001 From: "Tobin C. Harding" Date: Sun, 3 Sep 2023 13:55:26 +1000 Subject: [PATCH] Add one-ack carve outside In an effort to reduce review burden add so strict rules defining 3 times where we think it is acceptable for code to be merged with a single ACK. Feels a bit like we only just added the refactor carve out and now we are adding more carve outs, so whats next? We should take these rules seriously, if we are to be taken seriously. --- CONTRIBUTING.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c78ed997..736fc374 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -174,6 +174,23 @@ created a carve out to the 2-ACK rule. A PR may be considered for merge if it has a single ACK and has sat open for at least two weeks with no comments, questions, or NACKs. +#### One ACK carve-out + +We reserve the right to merge PRs with a single ACK [0], at any time, if they match +any of the following conditions: + +1. PR only touches CI i.e, only changes any of the `test.sh` scripts and/or + stuff in `.github/workflows`. +2. Non-content changing documentation fixes i.e., grammar/typos, spelling, full + stops, capital letters. Any change with more substance must still get two + ACKs. +3. Code moves that do not change the API e.g., moving error types to a private + submodule and re-exporting them from the original module. Must not include + any code changes except to import paths. This rule is more restrictive than + the refactor carve-out. It requires absolutely no change to the public API. + +[0] - Obviously author and ACK'er must not be the same person. + ## Coding conventions Library reflects Bitcoin Core approach whenever possible.