You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
for more information on helping with translations.
86
+
87
+
If a pull request is not to be considered for merging (yet), please
85
88
prefix the title with [WIP] or use [Tasks Lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#task-lists)
86
89
in the body of the pull request to indicate tasks are pending.
87
90
@@ -94,6 +97,8 @@ At this stage one should expect comments and review from other contributors. You
94
97
can add more commits to your pull request by committing them locally and pushing
95
98
to your fork until you have satisfied all feedback.
96
99
100
+
Note: Code review is a burdensome but important part of the development process, and as such, certain types of pull requests are rejected. In general, if the **improvements** do not warrant the **review effort** required, the PR has a high chance of being rejected. It is up to the PR author to convince the reviewers that the changes warrant the review effort, and if reviewers are "Concept NAK'ing" the PR, the author may need to present arguments and/or do research backing their suggested changes.
101
+
97
102
Squashing Commits
98
103
---------------------------
99
104
If your pull request is accepted for merging, you may be asked by a maintainer
@@ -102,10 +107,10 @@ before it will be merged. The basic squashing workflow is shown below.
102
107
103
108
git checkout your_branch_name
104
109
git rebase -i HEAD~n
105
-
# n is normally the number of commits in the pull
106
-
# set commits from 'pick' to 'squash', save and quit
107
-
# on the next screen, edit/refine commit messages
108
-
# save and quit
110
+
# n is normally the number of commits in the pull request.
111
+
# Set commits (except the one in the first line) from 'pick' to 'squash', save and quit.
112
+
# On the next screen, edit/refine commit messages.
113
+
# Save and quit.
109
114
git push -f # (force push to GitHub)
110
115
111
116
If you have problems with squashing (or other workflows with `git`), you can
@@ -153,14 +158,23 @@ behaviour of code within the pull request (bugs must be preserved as is).
153
158
Project maintainers aim for a quick turnaround on refactoring pull requests, so
154
159
where possible keep them short, uncomplex and easy to verify.
155
160
161
+
Pull requests that refactor the code should not be made by new contributors. It
162
+
requires a certain level of experience to know where the code belongs to and to
163
+
understand the full ramification (including rebase effort of open pull requests).
164
+
165
+
Trivial pull requests or pull requests that refactor the code with no clear
166
+
benefits may be immediately closed by the maintainers to reduce unnecessary
167
+
workload on reviewing.
168
+
156
169
157
170
"Decision Making" Process
158
171
-------------------------
159
172
160
-
The following applies to code changes to the BitCore Core project, and is not to be confused with overall BitCore
173
+
The following applies to code changes to the BitCore project (and related
174
+
projects such as libsecp256k1), and is not to be confused with overall BitCore
161
175
Network Protocol consensus changes.
162
176
163
-
Whether a pull request is merged into BitCore Core rests with the project merge
177
+
Whether a pull request is merged into BitCore rests with the project merge
164
178
maintainers and ultimately the project lead.
165
179
166
180
Maintainers will take into consideration if a patch is in line with the general
@@ -173,7 +187,7 @@ In general, all pull requests must:
173
187
the project (for example refactoring for modularisation);
174
188
- Be well peer reviewed;
175
189
- Have unit tests and functional tests where appropriate;
0 commit comments