123d0ec4cSDavid Quintana# Rules for managing Pull Requests 223d0ec4cSDavid Quintana 323d0ec4cSDavid QuintanaFor the sake of trying to maintain an acceptable number of open but idle PRs, the following rules should be considered: 423d0ec4cSDavid Quintana- If a PR has at least one approval, it can be merged after 1 week of waiting for additional comments. 523d0ec4cSDavid Quintana - If the change has at least 3 approvals or you consider it trivial enough, it may be merged right away. 623d0ec4cSDavid Quintana- If a PR stays in "changes requested" for too long, and there is no indication from the author that they are working on it, it shall be closed. 723d0ec4cSDavid Quintana - Rule of thumb: 2 weeks for a small PR. Can be longer if the PR is large. 823d0ec4cSDavid Quintana - The PR can be reopened at any point, if you have additional comments, or new changes have been done. 923d0ec4cSDavid Quintana- If you require a review from a particular person, assign the PR to that person. Don't just rely on the "review requested" feature of GitHub. 1023d0ec4cSDavid Quintana- Remember that PR labels exist. You can assign an appropriate label to a pull request to designate it's scope, grab additional attention or just for extra navigation possibilities. 1123d0ec4cSDavid Quintana- Don't feel obliged to comment everything you see, just for the sake of commenting. Be it on JIRA, GitHub, or even on IRC. 1223d0ec4cSDavid Quintana 1323d0ec4cSDavid QuintanaIn addition, in order to avoid coming off as rude to helpful contributors, please refrain from: 1423d0ec4cSDavid Quintana- Asking the contributor to do unrelated work 1523d0ec4cSDavid Quintana- Closing without providing a reason 1623d0ec4cSDavid Quintana- Merging with the intention to rewrite that code soon after 17*02a19c31SStanislav Motylkov 18*02a19c31SStanislav MotylkovBefore merging a PR, make sure it follows the [contributing rules](CONTRIBUTING.md#rules-and-recommendations), but more importantly: 19*02a19c31SStanislav Motylkov- Make sure the author has specified a real e-mail in all PR commits 20*02a19c31SStanislav Motylkov- If PR contains code or translations, make sure the author has not specified a nickname or alias, but a full legal name in all PR commits 21*02a19c31SStanislav Motylkov- If PR contains media (wallpapers, themes, icons, sounds) or out-of-code documentation, make sure the author has specified the name or alias in all PR commits 22*02a19c31SStanislav Motylkov- If PR contains mixed code with media changes, handle it as PR with code 23*02a19c31SStanislav Motylkov- Important notes before using "Squash and merge" strategy on a PR: 24*02a19c31SStanislav Motylkov - Make sure the author's name in GitHub profile matches one in commits. If this is not the case, ask the author to set it accordingly. 25*02a19c31SStanislav Motylkov - If the author does not want to set the name in GitHub profile: 26*02a19c31SStanislav Motylkov - "no squash merge" label needs to be added to a PR. 27*02a19c31SStanislav Motylkov - Make sure every commit message is formatted correctly as in [.gitmessage](https://github.com/reactos/reactos/blob/master/.gitmessage). 28*02a19c31SStanislav Motylkov - Finally in this case a PR has to be merged either using "Rebase and merge" strategy or manually. 29*02a19c31SStanislav Motylkov - By pressing "Squash and merge" button in a PR you can make sure the author does not use no-reply e-mail - 30*02a19c31SStanislav Motylkov under the commit message there will be a text label saying: `This commit will be authored by <address@email.com>` 31