[IPython-dev] Policy for closing pull requests

Brian Granger ellisonbg@gmail....
Sat Aug 11 20:53:10 CDT 2012


I should also mention that one of the reasons we tend to have PRs that
remain open for a long period of time is that we are working out
difficult technical issues.  In these cases I think we should use
issues for the long term discussion, rather than putting everything
into a PR that might not be the final solutions.

On Sat, Aug 11, 2012 at 6:46 PM, Brian Granger <ellisonbg@gmail.com> wrote:
> Hi,
>
> Ondrej has been going through the sympy pull request queue (they have
> 53 open, but had more than 70) and trying to close ones that are no
> longer active.  This as inspired me to think about these issues for
> IPython.  I am wondering if we can come up with a policy for closing
> pull requests.  Here is what I am thinking.
>
> * Let's use use pull requests for code that is actively being worked
> on and reviewed and that has a strong chance of being merged soon.
> * Open PRs should be in one of two states: waiting for review or
> waiting for additional code.  It should be obvious who the "person of
> next action" is.
> * When a PR is not in one of these states, it should be closed.
> * When a PR is in one of these states, but sits untouched for a long
> period of time, we close it and indicate in a comment what would need
> to be done to reopen it.
>
> In some rare cases we will outright reject a PR.  But in many cases,
> we will close PRs with a fairly positive statement like "this is
> promising, please reopen this PR after you do ..."  This is similar to
> the to "Someday/Maybe" category of Getting Things Done.
>
> I think this would help us keep our PR/review workflow moving and
> encourage people to revisit PRs that are inactive.
>
> Thoughts?
>
> Cheers,
>
> Brian
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger@calpoly.edu and ellisonbg@gmail.com



-- 
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