diff options
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 24 |
1 files changed, 18 insertions, 6 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f5d63517b1..aed6d79542 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -81,6 +81,10 @@ Examples: Qt: Add feed bump button Trivial: Fix typo in init.cpp +Note that translations should not be submitted as pull requests, please see +[Translation Process](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md) +for more information on helping with translations. + If a pull request is specifically not to be considered for merging (yet) please prefix the title with [WIP] or use [Tasks Lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#task-lists) in the body of the pull request to indicate tasks are pending. @@ -153,6 +157,14 @@ behaviour of code within the pull request (bugs must be preserved as is). Project maintainers aim for a quick turnaround on refactoring pull requests, so where possible keep them short, uncomplex and easy to verify. +Pull requests that refactor the code should not be made by new contributors. It +requires a certain level of experience to know where the code belongs to and to +understand the full ramification (including rebase effort of open pull requests). + +Trivial pull requests or pull requests that refactor the code with no clear +benefits may be immediately closed by the maintainers to reduce unnecessary +workload on reviewing. + "Decision Making" Process ------------------------- @@ -170,13 +182,13 @@ judge the general consensus of contributors. In general, all pull requests must: - - have a clear use case, fix a demonstrable bug or serve the greater good of + - Have a clear use case, fix a demonstrable bug or serve the greater good of the project (for example refactoring for modularisation); - - be well peer reviewed; - - have unit tests and functional tests where appropriate; - - follow code style guidelines; - - not break the existing test suite; - - where bugs are fixed, where possible, there should be unit tests + - Be well peer reviewed; + - Have unit tests and functional tests where appropriate; + - Follow code style guidelines; + - Not break the existing test suite; + - Where bugs are fixed, where possible, there should be unit tests demonstrating the bug and also proving the fix. This helps prevent regression. Patches that change Bitcoin consensus rules are considerably more involved than |