I just had a quick chat over the ASF's slack with Daniel Gruno from the infra team and they are rolling out the "triage role" [1] for non-committers, which AFAIK offers useful tools in this context:
* add/remove labels * assign reviewees * mark duplicates * close, open and assign to issues and PRs One does not disregard the other, just though it could be useful information to this topic, as maybe this cover some ground? Best, Jorge [1] https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization On Tue, Jun 29, 2021 at 3:10 PM Andrew Lamb <al...@influxdata.com> wrote: > The thing that would make me more efficient reviewing PRs is figuring out > which one of the open reviews are ready for additional feedback. > > I think the idea of a webapp or something that shows active reviews would > be helpful (though I get most of that from appropriate email filters). > > What about a system involving labels (for which there is already a basic > GUI in github)? Something low tech like > > (Waiting for Review) > (Addressing Feedback) > (Approved, waiting for Merge) > > With maybe some automation prompting people to add the "Waiting on Review" > label when they want feedback > > Andrew > > On Tue, Jun 29, 2021 at 4:28 AM Wes McKinney <wesmck...@gmail.com> wrote: > > > hi folks, > > > > I've noted that the volume of PRs for Arrow has been steadily > > increasing (and will likely continue to increase), and while I've > > personally had less time for development / maintenance / code reviews > > over the last year, I would like to have a discussion about what we > > could do to improve our tooling for maintainers to optimize the > > efficiency of time spent tending to the PR queue. In my own > > experience, I have felt that I have wasted a lot of time digging > > around the queue looking for PRs that are awaiting feedback or need to > > be merged. > > > > I note first of all that around 70 out of 173 open PRs have been > > updated in the last 7 days, so while there is some PR staleness, to > > have nearly half of the PRs active is pretty good. That said, ~70 > > active PRs is a lot of PRs to tend to. > > > > I scraped the project's code review comment history, and here are the > > individuals who have left the most comments on PRs since genesis > > > > pitrou 6802 > > wesm 5023 > > emkornfield 3032 > > bkietz 2834 > > kou 1489 > > nealrichardson 1439 > > fsaintjacques 1356 > > kszucs 1250 > > alamb 1133 > > jorisvandenbossche 1094 > > liyafan82 831 > > lidavidm 816 > > westonpace 794 > > xhochy 770 > > nevi-me 643 > > BryanCutler 639 > > jorgecarleitao 635 > > cpcloud 551 > > sunchao 536 > > ianmcook 499 > > > > Since we're probably stuck using GitHub to receive code contributions > > (as opposed to systems — Gerrit is one I'm familiar with — that > > provide more structure for reviewers to track the patches they "own" > > as well as the outgoing/incoming state of reviews), I am wondering > > what kinds of tools we could create to make it easier for maintainers > > to keep track of PRs they are shepherding through the contribution > > process. Ideally this wouldn't involve maintainers having to engage in > > some explicit action like assigning themselves as a PR reviewer. > > > > Here's one idea: a web application that displays "your reviews", a > > table of PRs that you have interacted with in any way (commented, left > > code review, assigned as reviewer, someone mentioned you, etc.) sorted > > either by last commit or last comment to assess "freshness". So if you > > comment on a PR or leave a code review, it will automatically show up > > in "your reviews". It could also indicate whether there has been > > activity on the PR since the last time you interacted with it. > > > > Having now used the GitHub API to pull comments from PRs for the above > > analysis, there is certainly enough information available to help > > create this kind of tool. I'd be willing to contribute to building the > > backend of such a web application. > > > > This is just one idea, but I am curious to hear from others who are > > spending a lot of time doing code review / PR merging to see what > > might help them use their time more effectively. > > > > Thanks, > > Wes > > >
