Clearing the pull request queue

[Aaron Meurer]

We currently have 92 open pull requests, and that number is only going
to get much worse in April if we are accepted for GSoC. Working on
the GSoC application is high priority now, but we should also focus on
clearing the pull requests a bit.

For those open pull requests that are marked as WIP, we need to
determine exactly what work still needs to be done, and more
importantly, if it is essential or not that the pull request not be
merged until that work is completed. It's tempting to mark a pull
request as WIP until you have done all the work you want to do, but if
the work that is done so far is OK, then it should be merged, and new
work put in a new pull request.

I think there are several pull requests that are fine to go. They just
need a final review (or a review at all). My two most recent pull
requests (1916 and 1876) fall into this category.

For those that really do have work to do, add a TODO to the pull
request description (or a comment if you don't have push access). It's
nice to use the GitHub Markdown checkbox lists, which work like

- [ ] item1
- [ ] item2

Then the items can be checked off as they are completed, and once
everything is checked, you will know that it is done.

Better yet, send a pull request to the person who made the pull
request fixing the issues. Just fix the issues in your branch, and go
like you are making a pull request to SymPy, but then change it to go
against the person's branch. If GitHub doesn't show the person's name
in the list, go like you are sending a pull request to someone else
and then change the name in the url to the one you want.

And even though we do want to clear the pull request queue, please
don't merge any pull request unless it has a passing Travis review, or
if Travis is acting up, a passing SymPy Bot review. Clearing the pull
request queue is important, but keeping tests passing in master is
more important.

Aaron Meurer

[Ondřej Čertík]

I would suggest to adopt the ipython approach:

* create a policy like:
https://github.com/ipython/ipython/wiki/Dev:-Closing-pull-requests

* find pull requests that are waiting for a response of the original
author for more than a month (or require large redesign), close them
and post a link to our policy

* create a new issue with a link to the PR

Here is an example of my own PR, that I simply don't have time to finish up:

https://github.com/ipython/ipython/pull/2504

That is the only reasonable way in my opinion. The PR queue should be
for pull requests that are being worked on.
There is absolutely nothing wrong with closing a pull request that
nobody has time to finish.

I went ahead and created our own policy page here:

https://github.com/sympy/sympy/wiki/Dev:-Closing-pull-requests

Feel free to modify it/update it. Once we all agree with the text,
I'll go over old PRs and close them according to the policy (plus
create an issue with it).

Ondrej

[Aaron Meurer]

I renamed the page to
https://github.com/sympy/sympy/wiki/Closing-pull-requests to better
match our naming scheme (and also be less painful to open in the
terminal), and I added a part about preferring to try to complete
someone else's work rather than just close the pull request.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy?hl=en-US.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>