Hacker News new | ask | show | jobs
by demorro 78 days ago
> you spend a LOT of time trying to get your PR reviewed.

I've fixed this issue in several teams I've joined. Maybe some people won't understand this, as I didn't until I observed it multiple times over.

There are teams out there, perhaps the majority, that simply leave the decision as to when a PR will be reviewed nebulous, and at the discretion of team members. There is no formal obligation to do them in a timely manner, and there are no consequences if they are not done.

The solve to this is obvious and easy:

- Automatically assign specific people to PRs. No general team assignment. The submitter can add specific people in addition to PR's if they need domain experts, but the normal case is random assignment.

- Require PR's to be done within 24 working hours. If you cannot do this for whatever reason, you must communicate this to the team.

- There are consequences if you violate this policy.

The last one is the hard part for cowardly teams and cowardly managers. You do have to stay on top of it initially, and even when people have accepted this and gotten used to it, you can't forget about it because people will drift.

This isn't to say I'm against the direct integration model you propose, I can also see the appeal, it's just that problems with PR flows are mostly about cowardly management, not anything much to do with the actual process.

1 comments

At a previous job, it was the on-call engineer's duty to review PRs, as one of their responsibilities. A PR is just another interrupt, right?

We also paired this with giving the on call engineer near total freedom with what to do during their shifts, similar to 20% time (which was about the same percentage; 5 team members, weekly on call rotations.) They chose which tickets to pick up from the backlog, which also helped keep up with maintenance and taking care of bugs and issues that otherwise wouldn't get prioritized.