Any other thoughts about process to manage the backlog?
On Thu, May 16, 2019 at 2:58 PM Wes McKinney <wesmck...@gmail.com> wrote: > > 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
