[IPython-dev] Policy for closing pull requests

Brian Granger ellisonbg@gmail....
Sun Aug 12 23:53:35 CDT 2012


On Sun, Aug 12, 2012 at 9:33 PM, Fernando Perez <fperez.net@gmail.com> wrote:
> On Sat, Aug 11, 2012 at 7:17 PM, Aaron Meurer <asmeurer@gmail.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
merge.
* 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
personal.

Thoughts?

Cheers,

Brian


>
> How does that sound?
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com


More information about the IPython-dev mailing list