[volent]

> PRs should always be prioritized. Aim for review SLA of 1 hour.

I don't agree with this. For the sake of the argument let's agree that a review takes less than 1 hour (which is definitely not always the case). That would mean that an Engineer needs to check his emails / notification more than once an hour to meet this SLA.

This is totally unproductive IMO.

I like most of the other points though, nice list.

[bjterry]

If you have a PR review that takes over 1 hour, it's very unlikely that the reviewer will be applying the kind of focus that it takes to really review. For the typical Silicon Valley style development role.

1 hour SLA would be astonishingly, irresponsibly fast. In the real world, in small teams that put in a concerted effort, the outlier best average review times are like 6 hours based on real data. Ideally you would want to be within a work day, but if you are under 24 hours you are doing better than 90% of teams working at random BigCos the world over, I bet.

[devo-x-lie]

This all really depends on the maturity of the organisation and the team.

"1 hour SLA would be astonishingly, irresponsibly fast". Yes this can be true for a lot of cases, but at the same time it's nothing 'astonishing' or 'irresponsible'. Again it just depends in what state and maturity level the team and organisation are at.

Also, I think you are talking more from dev side of things? Would that be a good assumption to make? If that's the case then your points are very valid, but don't forget a lot of ops-like-teams work on code bases significantly smaller than coding projects and as such that SLA is totally fine.

Let's also remember that an 'SLA' for a review should be a guideline, not a factor to be always meet. There are always factors that will influence this.

[bjterry]

Yes, I was referring to the context "For the typical Silicon Valley style development role" I mentioned.

Part of this may be that we are using different definitions of SLA. Normally when people around me say SLA, they mean something that is an upper bound pretty much always expected to be met (or else there are consequences of some sort). If you are referring to a softer agreement than that, it could make sense. If you were holding 1 hour as an SLA by my definition, that would mean you pretty much need to always have someone on deck to immediately review all PRs, to be safe.

I mostly posted because I don't want people who are less experienced to get the impression that 1 hour average review turnaround is normal or necessary in a typical development environment. In specialist roles, sure. For example, if you told me your work was responding to support tickets created by customers, and it sometimes resulted in PRs to modify your infrastructure-as-code, I could see the team working out a system to always get reviews within an hour.

[taude]

I agree with this. I don't know what cadence that anything needs to be on the release train that quick on any company of any size. My teams typically do PRs are part of their morning routines, and when they're occasionally interrupted for an emergency situation.

[devo-x-lie]

You are right, having this one rule for all will not make a lot of sense. But I take it just as an example, in my place the nature of our team and work is such that this SLA can and is meet without any problems.

Looking at my last place, it's more like a 24hour SLA and that would still be ambitious in some case.

Maybe try to experiment with this number and see if you can agree on something more optimal? (There is nothing hard / time consuming in having a quick check in your emails and messages once per hour. I hate this idea of people working in teams but always wanting to not be disturbed ALL the time.)

[warpech]

In my team, we review PRs first thing in the morning the following day. It is for the benefit of everyone. People are less distracted and know that they can get occupied with other things by working at their own schedule until the end of the day.

[ProZsolt]

Yes, that's my daily routine. Sipping coffee and reviewing code. During the day I'm happy to re-review code if I asked for a modification because I only have to check a small part of the code and I'm already familiar with the whole concept.

Reviewing any non-trivial complexity code has a big task switch cost. Reviewing code during the day is bad for productivity.