[IPython-dev] Policy for closing pull requests
Sun Aug 12 23:53:35 CDT 2012
On Sun, Aug 12, 2012 at 9:33 PM, Fernando Perez <firstname.lastname@example.org> wrote:
> On Sat, Aug 11, 2012 at 7:17 PM, Aaron Meurer <email@example.com> wrote:
>> One other important rule that we have in SymPy is that if we close a
>> pull request that still needs work (as opposed to an outright
>> rejection), we make sure that it is mentioned in an open issue.
>> Otherwise, it will be forgotten forever.
> With Aaron's additional point, I'm +1 on the idea, whereas the
> original proposal seemed too aggressive to me. I understand the need
> to optimize our limited resources so we can focus on code that has a
> hope of getting merged, but as originally presented I think that it
> pushed too hard in that direction and had the danger of alienating
> contributors (we don't want to 'solve' our current problem of having
> too many open PRs simply by losing contributors, that would be
> throwing out the baby with the bathwater).
> So I'm +1 on the original proposal, but once amended with:
> - Every time we close a PR because it has become 'dormant' (but one we
> assume would get merged with some extra work), we do two things:
> 1. In the closing comment, explain clearly to the author this, so they
> realize the closing isn't a rejection, and that the simple act of
> pushing a few commits would be sufficient to get it reopened (and
> possibly merged if that completes what was missing).
> 2. We create a regular issue linking to this PR, with a label
> 'dormant-PR'. This would let us quickly use the issue sorter to have
> a look at dormant PRs, which are also candidates for sprints, when a
> core developer wants to do some quick housecleaning, etc.
I agree that Aaron's idea is important and I am +1 on implementing
this as you describe. I just want their to be agreement on the
criteria we use to decide *when* we take such an action. How do you
feel about the following:
* When a PR has been reviewed and is waiting additional code and sits
in this state untouched for 1 month.
* When the review process can't seem to reach a solid conclusion
because there are larger issues or technical details that have to be
worked out. Once it reaches this point and sits for a month, we
should close the PR and open an issue to continue the larger
discussion. I suppose if it becomes obvious that it is in this state
in a shorter amount of time, we could close it earlier. The goal is
to have PRs reflect code that is actively moving forward towards a
* What do we do about PRs that sit for a month waiting for review?
We could go with a much simpler approach and say "regardless of the
reason if a PR hasn't been touched for a month, we close it and open
and issue." A more uniform criteria might come across as less
> How does that sound?
> IPython-dev mailing list
Brian E. Granger
Cal Poly State University, San Luis Obispo
firstname.lastname@example.org and email@example.com
More information about the IPython-dev