hi Micah, This sounds like a reasonable proposal, and I agree in particular for regular contributors that it makes sense to close PRs that are not close to being in merge-readiness to thin the noise of the patch queue
We have some short-term issues such as various reviewers being busy lately (e.g. I was on vacation in April, then heads down working on ARROW-3144) but I agree that there are some structural issues with how we're organizing code review efforts. Note that Apache Spark, with ~500 open PRs, created this dashboard application to help manage the insanity https://spark-prs.appspot.com/ Ultimately (in the next few years as the number of active contributors grows) I expect that we'll have to do something similar. - Wes On Thu, May 16, 2019 at 2:34 PM Micah Kornfield <emkornfi...@gmail.com> wrote: > > Our backlog of open PRs is slowly creeping up. This isn't great because it > allows contributions to slip through the cracks (which in turn possibly > turns off new contributors). Perusing PRs I think things roughly fall into > the following categories. > > > 1. PRs are work in progress that never got completed but were left open > (mostly by regular arrow contributors). > > 2. PR stalled because changes where requested and the PR author never > responded. > > 3. PR stalled due to lack of consensus on approach/design. > > 4. PR is blocked on some external dependency (mostly these are PRs by > regular arrow contributor). > > > A straw-man proposal for handling these: > > 1. Regular arrow contributors, please close the PR if it isn't close to > being ready and you aren't actively working on it. > > 2. I think we should start assigning reviewers who will have the > responsibility of: > > a. Pinging contributor and working through the review with them. > > b. Closing out the PR in some form if there hasn't been activity in a > 30 day period (either merging as is, making the necessary changes or > closing the PR, and removing the tag from JIRA). > > 3. Same as 2, but bring the discussion to the mailing list and try to have > a formal vote if necessary. > > 4. Same as 2, but tag the PR as blocked and the time window expands. > > > The question comes up with how to manage assignment of PRs to reviewers. I > am happy to try to triage any PRs older then a week (assuming some PRs will > be closed quickly with the current ad-hoc process) and load balance between > volunteers (it would be great to have a doc someplace where people can > express there available bandwidth and which languages they feel comfortable > with). > > > Thoughts/other proposals? > > > Thanks, > > Micah > > > > P.S. A very rough analysis of PR tags gives the following counts. > > 29 C++ > > 17 Python > > 8 Rust > > 7 WIP > > 7 Plasma > > 7 Java > > 5 R > > 4 Go > > 4 Flight
