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.
This commit is contained in:
Tobin C. Harding 2023-09-03 13:55:26 +10:00
parent c06c9beb01
commit 4222e4d817
No known key found for this signature in database
GPG Key ID: 40BF9E4C269D6607
1 changed files with 17 additions and 0 deletions

View File

@ -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 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. 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 ## Coding conventions
Library reflects Bitcoin Core approach whenever possible. Library reflects Bitcoin Core approach whenever possible.