> So I've been brainstorming with Ian and Andrew about how to manage the
> pull request queue and such better.  We are trying to find ways to reduce
> the signal to noise ratio for maintainers, as well as do a better job of
> communication about intent with the pull requests.  Here's what we'd like
> to try:

> *Open/Closed*

> Going forwards we are going to treat open/closed a little differently than
> we do currently.  If a pull request is ready to be reviewed (by maintainers
> and non-maintainers) it will be left open.  If there are changes that need
> to be made, unit tests that need to be fixed, code style issues to be
> cleaned up, missing documentation, etc. then comments will be left and the
> pull request will be closed until the developer has completed the changes.
>  Our expectation is that once the changes have been made developers will
> re-open the pull request for review.

> What this effectively does is ensure that at all times we know what is
> ready to be looked at, and what is still being worked on.  It is important
> to understand that just because we close it doesn't mean that it is
> rejected, but we are simply saying that it needs some work before it can be
> considered for further review.

> *Milestones*
> *
> *
> Because of the change in the way we treat Open/Closed state for pull
> requests (and for housekeeping purposes) we are also going to be utilizing
> the issue tracker milestones feature going forward.  If we assign a
> milestone for a pull request you can consider the pull request accepted for
> the given release (milestone) assuming that we work out all the kinks.  If
> there are changes we'd like made, or test/style fixes than we will assign a
> milestone and close the issue.  Hopefully this will help us track what is
> being worked on in a given release, what was done in given releases, and
> communicate better with all of you about if and when we want to include the
> code you've submitted for review.

> *Browsing Issues*

> Those of you wanting to see what is going on in a given release would be
> better served viewing things through the issue tracker in this way of
> working.  That will give you an ability to look at everything attached to a
> given milestone.  Those of you who want to help us review code (and please
> do) you can trust that everything in the open pull request queue is ready
> for review.  Should make it much easier to find things to look at and
> comment on.

> Nothing is perfect, but our hope is that this will help us manage things a
> bit better and make it easier for all of you to understand what is going on
> and what is being worked on in a given release.  To those of you submitting
> code, hopefully it will be more clear if/when we expect to get your code
> merged into the codebase.

> Thoughts?

> - Louis