Thanks for taking a look at this. I appreciate your efforts!
On Mon, Oct 8, 2012 at 9:43 PM, Louis Landry <louislan...
> Hi all,
> 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:
> 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.
> 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.
> - Louis