Updates to Reviewing a Pull Request

This commit is contained in:
Parker Moore 2016-06-16 17:07:16 -07:00
parent 4afb407304
commit 0c7693f7b9
No known key found for this signature in database
GPG Key ID: 193CDEBA72063C58
1 changed files with 4 additions and 2 deletions

View File

@ -18,12 +18,14 @@ If your response requires a response on the part of the author, please add the `
## Resolve Quickly
Similarly, we should aim to resolve pull requests quickly. If a pull request introduces a feature which does not fit into the core purpose or goal of the project, close it prompty with a kind explanation of why it is not acceptable.
Similarly, we should aim to resolve pull requests quickly. If a pull request introduces a feature which does not fit into the core purpose or goal of the project, close it promptly with a kind explanation of why it is not acceptable.
Leave detailed comments wherever possible. Provide the contributor with context around why the change you are requesting is necessary, or why the question you are asking is important to resolve. The more context we can clearly communicate to the contributor, the better able
Leave detailed comments wherever possible. Provide the contributor with context around why the change you are requesting is necessary, or why the question you are asking is important to resolve. The more context we can clearly communicate to the contributor, the better able the contributor is to provide high-quality patches.
You may close a pull request if more than 30 days pass without a response from the author.
In some cases, review will involve many weeks of back-and-forth. As long as communication continues, this is fine. Ideally, any PR would be capable of resolution within 30 days of it being opened.
## Look for Tests
If this is a code change, are there tests for the updated or added behaviour? Shipping a version with bugs is inevitable, but ensuring changes are tested helps keep bugs and regressions to a minimum.