-
Notifications
You must be signed in to change notification settings - Fork 386
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
MarcoFalke
committed
Sep 23, 2018
1 parent
d73205e
commit fae9e84
Showing
1 changed file
with
31 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,31 @@ | ||
Pull requests without a rationale and clear improvement may be closed | ||
immediately. | ||
|
||
Please provide clear motivation for your patch and explain how it improves | ||
Bitcoin Core user experience or Bitcoin Core developer experience | ||
significantly. | ||
|
||
* Any test improvements or new tests that improve coverage are always welcome. | ||
* All other changes should have accompanying unit tests (see `src/test/`) or | ||
functional tests (see `test/`). Contributors should note which tests cover | ||
modified code. If no tests exist for a region of modified code, new tests | ||
should accompany the change. | ||
* Bug fixes are most welcome when they come with steps to reproduce or an | ||
explanation of the potential issue as well as reasoning for the way the bug | ||
was fixed. | ||
* Features are welcome, but might be rejected due to design or scope issues. | ||
If a feature is based on a lot of dependencies, contributors should first | ||
consider building the system outside of Bitcoin Core, if possible. | ||
* Refactoring changes are only accepted if they are required for a feature or | ||
bug fix or otherwise improve developer experience significantly. For example, | ||
most "code style" refactoring changes require a thorough explanation why they | ||
are useful, what downsides they have and why they *significantly* improve | ||
developer experience or avoid serious programming bugs. Note that code style | ||
is often a subjective matter. Unless they are explicitly mentioned to be | ||
preferred in the [developer notes](/doc/developer-notes.md), stylistic code | ||
changes are usually rejected. | ||
|
||
Bitcoin Core has a 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. |