|
|
@ -157,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 |
|
|
|
Project maintainers aim for a quick turnaround on refactoring pull requests, so |
|
|
|
where possible keep them short, uncomplex and easy to verify. |
|
|
|
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 |
|
|
|
"Decision Making" Process |
|
|
|
------------------------- |
|
|
|
------------------------- |
|
|
|