Automatically close stale PRs? https://github.com/probot/stale
On Tue, May 21, 2019 at 11:00 AM Wes McKinney <wesmck...@gmail.com> wrote: > 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 >
