From 0c7693f7b918c6d603119281fec9165d61177122 Mon Sep 17 00:00:00 2001 From: Parker Moore Date: Thu, 16 Jun 2016 17:07:16 -0700 Subject: [PATCH] Updates to Reviewing a Pull Request --- docs/reviewing-a-pull-request.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/reviewing-a-pull-request.md b/docs/reviewing-a-pull-request.md index feea47ec..b2c3e0de 100644 --- a/docs/reviewing-a-pull-request.md +++ b/docs/reviewing-a-pull-request.md @@ -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.