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:
parent
c06c9beb01
commit
4222e4d817
|
@ -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.
|
||||||
|
|
Loading…
Reference in New Issue