|
|
|
|
|
|
by devo-x-lie
2244 days ago
|
|
|
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. |
|
|
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.