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