|
|
@ -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
|
|
|
|
-------------------------
|
|
|
|
-------------------------
|
|
|
|