I have a stack of PRs waiting for review, some quite old.
My only New Year’s resolution was to help reduce the backlog, including but not limited to my own, by helping to review and also triage and answer questions, on the theory that reducing the overall workload will free up resources for the difficult work of ingesting contributions without compromising quality.
My other goal, which I haven’t fully put into practice, is to make a PR simple to review. That means no extraneous edits (a challenge for my itchy fingers), and also making a clear argument for why the PR is worth reviewing and answering any open questions about it. The reviewer should not have to be expert, but should be persuaded by some combination of ticket comments and code inspection that the PR pulls its weight.
Even one LOC or LOCC (lines of code changed, a coinage?) is a cost. The reviewer’s (or reviewers’) time is a fixed cost. Is it worth the risk of breakage and costing more time in future?
I’m pretty sure all my one–LOCC PRs broke something; that goes up exponentially for half-LOCC.
The real limitation on an “academic” project is that everyone is involved in academia and is probably stretched somewhat thin, across responsibilities for studying, teaching, and research. (That is, the limitation is not that the project has goals that are “merely academic”.)
It’s unreasonable to expect one person to take on management of the backlog, though it would be nice if one person were prominently assigned the duty of fielding requests for review. That would be like triaging issues, except triaging PRs means judging if it’s a simple review and who might be in the best position to take a look at it.
The other factor is that the team has internal discussions about priorities and future direction, and none of that is visible to the outside. (I think that is OK.) So the point person doing triage (of requests for review) must be behind that firewall and know who has exams, who is swamped, and maybe who knows what. They must also know who got a job and is not available to review any more.
If I felt I had a PR that “moved the needle”, I would want to at-notify that point person. I don’t remember off-hand if any of my open PRs even make the needle oscillate a little.
Obviously, the most important issue right now is that publishLocal is broken (because that affects me directly). I have no way of knowing if the team has a plan for that, or it’s blocked by some other work on the build, the library, or the doc tool, etc. The other limitation of an academic project is that the smart people on the team would say, just use cs to fetch your dependencies and run the scala task from sbt, what’s the problem? That anecdote is to illustrate that priorities are relative to immediate needs.
I plan to renew my resolution for Lunar New Year.