Skip to content

Commit af4b8a3

Browse files
author
MarcoFalke
committed
Merge #14217: doc: Add GitHub pr template
fae9e84 doc: Add GitHub pr template (MarcoFalke) Pull request description: Bitcoin Core has a very thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. Authors should provide clear motivation for patches and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly. Tree-SHA512: 83b379d75934089f13ba173e6ec847845f954f10f83e406ef9722836aa093170c612b4214f22cd5939d59f66a50f5d0e52aa0059423e8e7261bb176f1c546a08
2 parents 9b8bb5f + fae9e84 commit af4b8a3

File tree

1 file changed

+31
-0
lines changed

1 file changed

+31
-0
lines changed

.github/PULL_REQUEST_TEMPLATE.md

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
Pull requests without a rationale and clear improvement may be closed
2+
immediately.
3+
4+
Please provide clear motivation for your patch and explain how it improves
5+
Bitcoin Core user experience or Bitcoin Core developer experience
6+
significantly.
7+
8+
* Any test improvements or new tests that improve coverage are always welcome.
9+
* All other changes should have accompanying unit tests (see `src/test/`) or
10+
functional tests (see `test/`). Contributors should note which tests cover
11+
modified code. If no tests exist for a region of modified code, new tests
12+
should accompany the change.
13+
* Bug fixes are most welcome when they come with steps to reproduce or an
14+
explanation of the potential issue as well as reasoning for the way the bug
15+
was fixed.
16+
* Features are welcome, but might be rejected due to design or scope issues.
17+
If a feature is based on a lot of dependencies, contributors should first
18+
consider building the system outside of Bitcoin Core, if possible.
19+
* Refactoring changes are only accepted if they are required for a feature or
20+
bug fix or otherwise improve developer experience significantly. For example,
21+
most "code style" refactoring changes require a thorough explanation why they
22+
are useful, what downsides they have and why they *significantly* improve
23+
developer experience or avoid serious programming bugs. Note that code style
24+
is often a subjective matter. Unless they are explicitly mentioned to be
25+
preferred in the [developer notes](/doc/developer-notes.md), stylistic code
26+
changes are usually rejected.
27+
28+
Bitcoin Core has a thorough review process and even the most trivial change
29+
needs to pass a lot of eyes and requires non-zero or even substantial time
30+
effort to review. There is a huge lack of active reviewers on the project, so
31+
patches often sit for a long time.

0 commit comments

Comments
 (0)