PR duty

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Apr 5 22:18:38 UTC 2018


On Thu, Apr 05, 2018 at 09:42:50PM +0000, Meta via Digitalmars-d wrote:
> On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu wrote:
> > Hi folks, I was thinking of the following.
> > 
> > To keep the PR queue trim and in good shape, we'd need at least one
> > full-time engineer minding it. I've done that occasionally, and the
> > queue size got shorter, but I couldn't do much else during that
> > time.
[...]
> Something adjacent but related that I've been wanting to suggest for
> awhile is that we hold a semi-weekly or weekly scrum for Phobos and/or
> dmd (with possibly overlapping but not necessarily identical groups).
> 
> I'm thinking that you would attend the Phobos one and Walter the dmd
> one (I don't think it'd be necessary to have you at _every_ meeting).
> The idea is that we go over each PR opened that week and decide what
> to do with them (merge, close, needs guidance, needs W/A decision,
> etc.) The scrum master that sprint (which could rotate between people)
> is responsible for getting a decision from you or Walter on items (if
> you're not at the scrum), ensuring action items are followed up on by
> those they're assigned to, just generally coordination and
> administrative tasks...
> 
> The goal is to improve the team's velocity such that we are handling
> every PR that comes in for that week, and then start eating into the
> backlog. IMO that backlog should be prioritized, but I'm not certain
> how to go about that yet.
[...]

One thing I've done in the past when I got some spare time was to plunge
into the oldest end of the PR queue (just go straight to page 4 or page
5, or sort by least activity, etc.) and look for PRs that have stalled.
The "stalled" tag helps find them easily, but I've found that the most
profitable PRs are the ones that non-controversial, i.e., don't have
other tags that implies some complexity (e.g., blocked, needs work).
"Needs rebase" is generally a good tag to target.  Once such PRs are
identified, dig into why they've stalled: quite often, it's because
somebody dropped the ball (original submitter stopped working on it, or
reviewers overlooked it, or it needs a rebase because a conflicting
change was committed).

In the case of rebase, since github lets us have write access to PRs,
it's often quite easy to just pull the PR locally, rebase it yourself,
and push the changes back. (Sebastian has a very nice how-to on the wiki
documenting how to do this.)

In the case the ball was just dropped, just ping the submitter / a
random bunch of Phobos reviewers to get things going again.  If there
is no response for about a week or so, ping again.  In general, these
PRs are your excuse to make a pest of yourself and bother people until
they start doing something again. :-P

The last time I did this, I managed to declog about 15-20 PRs over a
course of 2-3 weeks (dropped the PR queue to <100).  But I got too busy
to continue, and since that time the PR queue has lengthened again.  So
it's an ongoing battle.

But if say we had 2-3 people doing this on a regular basis (you don't
even need commit access if you're just pinging people), I think we can
easily get the PR queue size under control again.  My personal goal was
to push it down to <50 -- we actually managed to do that once, a few
years back, we almost got it down to one page, but then one of the
people involved quit contributing to Phobos and things started piling up
again.


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter


More information about the Digitalmars-d mailing list