Thank you very much for sharing this data, Tyler (and to the team that researched and analysed it, as well). I think it shows that the train has been pretty successful in mitigating the issues it was intended to improve.
I note the data points that show there has been a significant and clear trend toward fewer comments per patch. This would be worth investigating further. Iis the total number of reviews pretty consistent, or is it increasing or decreasing? Is it possible that developers have become more proficient at writing patches to standard, and thus fewer comments are required? Or could it be that, because more time is invested in writing patches (assuming that more patches = more time writing them), there is less time for review?
There can be other reasons as well, three reasons that I have seen anecdotally and not in any way scientific are:
- Reducing average size of patches. This is a good practice in software engineering and slowly being adapted by developers. Smaller patches leading to more straightforward review.
- Rise of simple refactor patches. With lots of refactoring work being done (specially breaking down monster classes:
https://monmon.toolforge.org), we have a lot of patches fixing deprecations (in core and extensions) and other cleanup work that are useful but really don't require much discussion.
- Better test coverage. I remember back then when test coverage was much lower, most of the review comments were something along the lines of "I tested it locally and it broke twenty million things". With better test coverage we have now (specially browser tests, api tests, the rest of e2e tests), now these are caught by jenkins before a human reviewer finds them (or worse, show up in production) which is good :)
The reality is probably a combination of all three plus other reasons.