[terrortrain]

I implemented a policy of "loom video, for all PR", at my last company.

Every video should include: an explanation of the problem, a walkthrough of the patch, a recording of the result.

PRs never sat long, because the willpower it took to understand the problem, the solution, and how to replicate/test manually (if you feel that necessary) was drastically reduced.

It shifts the burden of extra work to the requestor, who has motivation to get things merged.

Additionally, git blame became infinitely more useful.

[sam0x17]

We do this as well for anything that touches the UI, and oh my god has it made it easier for me to approve things (or deny them) when it's a bunch of UI stuff

[mchusma]

I like this. We also strongly suggest that engineers do PRs first thing in the day. This has the benefit of minimizing interruptions, and a daily cadence to PRs is typically pretty good. Basically, interrupting your work to do PRs is generally bad. So that basically leaves the beginning of the day, right after a big interruption. (we try to not be religious about this though)

[spacemanmatt]

I've started pushing back on changes that don't start with a narrated video discussing the changes against current production. I wanted them to supply the page, element, and change description, but video just works better for them.