> understand the decision making process that was being followed This should be documented in the PR in human language, hopefully with some backwards and forwa

> understand the decision making process that was being followed This should be documented in the PR in human language, hopefully with some backwards and forwards and questions asked and answered. I'll frequently go back and document why the PR wound up the way it did even after everything has been merged and shipped because some discussion a day later makes me realize that the information had never been captured. And those can be options that were never in the commit history because they weren't the path that was taken. Then a few years later you can read the PR and see that there were different options, that some of them were rejected as not meeting the actual requirements, there might have been concern about breaking changes, the very issue that has cropped up later might have been anticipated but a simpler solution was used on the expectation that the complicated solution wouldn't be necessary (and now it is necessary). The "why" of a change is a lot more than the history of the person typing on the keyboard and making commits, there's a whole lot of thinking that goes into a change which is never reflected in a single line of code.