Merge bitcoin/bitcoin#34388: doc: Explain that low-effort pull requests may be closed

fa15a8d2d03b0099b97262e47a8cbf685c29dd49 doc: Explain that low-effort pull requests may be closed (MarcoFalke)

Pull request description:

  Lately, there seems to be a rise in low-effort pull requests. For example, where a contributor does not seem to understand the changes they are submitting, or it becomes clear that they have not tested the changes at all.

  I don't think such pull requests are helpful, as they extract precious review time, which could be better spent on reviewing pull requests by reviewers who care about understanding the changes they are submitting, and who ensure their changes are sound and tested.

  So document that such low-effort pull request may be closed.

ACKs for top commit:
  l0rinc:
    ACK fa15a8d2d03b0099b97262e47a8cbf685c29dd49
  willcl-ark:
    ACK fa15a8d2d03b0099b97262e47a8cbf685c29dd49
  dergoegge:
    ACK fa15a8d2d03b0099b97262e47a8cbf685c29dd49
  pinheadmz:
    ACK fa15a8d2d0

Tree-SHA512: ba880f61c90c95e1e9007e337bad1a612a53ca85448f0ebfe97b34139489f22e5f709b8a0e302b11f71213e3b7863ab36ebd89b5c11cd550022d96493f917dd7
This commit is contained in:
merge-script 2026-01-26 09:59:10 +00:00
commit 6472ba06c3
No known key found for this signature in database
GPG Key ID: 2EEB9F5CC09526C1

View File

@ -78,6 +78,13 @@ The codebase is maintained using the "contributor workflow" where everyone
without exception contributes patch proposals using "pull requests" (PRs). This without exception contributes patch proposals using "pull requests" (PRs). This
facilitates social contribution, easy testing and peer review. facilitates social contribution, easy testing and peer review.
Pull request authors must fully and confidently understand their own changes
and must have tested them. Contributors should mention which tests cover their
changes, or include the manual steps they used to confirm the change.
Contributors are expected to be prepared to clearly motivate and explain their
changes. If there is doubt, the pull request may be closed.
Please refer to the [peer review](#peer-review) section below for more details.
To contribute a patch, the workflow is as follows: To contribute a patch, the workflow is as follows:
1. Fork repository ([only for the first time](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)) 1. Fork repository ([only for the first time](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo))
@ -338,6 +345,11 @@ reviewers that the changes warrant the review effort, and if reviewers are
"Concept NACK'ing" the PR, the author may need to present arguments and/or do "Concept NACK'ing" the PR, the author may need to present arguments and/or do
research backing their suggested changes. research backing their suggested changes.
Moreover, if there is reasonable doubt that the pull request author does not
fully understand the changes they are submitting themselves, or if it becomes
clear that they have not tested the changes on a basic level themselves, the
pull request may be closed immediately.
#### Conceptual Review #### Conceptual Review
A review can be a conceptual review, where the reviewer leaves a comment A review can be a conceptual review, where the reviewer leaves a comment