The PR that I put in before everybody else's was summarily ignored because everybody was busy getting their own stuff in. I spent cram day rebasing my PR at least a half-dozen times as commits flew into the main branch. A few minutes before cut-off I asked in a team call if I could get a review; my team lead told me that there was no time and that it would have to wait.
Needless to say I've since found a team that does the opposite (reviews each others' code in a timely and constructive manner). I really enjoy working with people that care about delivering value and helping others... it's vastly improved my job satisfaction.
While I'm sure a lot of people will find this tool useful, I believe it will also help disfunctional teams last longer, which just means that the real problems (like, why people don't review code in timely fashion) will take longer to resolve.
As always, just my two cents based on my experience :)
There's some kind of game theory dynamic going on where I don't think the outcome is really ideal, even if most people involved are trying to make it work.
(Edit) For big changes I've seen people schedule 30-minute review meetings. We all hate meetings but I don't think it's a bad idea.
The longer the cycle, the more contexts to be juggled and the more effort to juggle them.
In practice most devs spend 90% coding and 10% hastily rushing through reviews.
Some people assign timeslots for reviews, but when deadline is pressing, all the timeslots go away.
The only solution that I have seen, and am happy to be a part of currently, is to have a close coworking team that's responsive. In short, it's not the tooling, it's the people.
It's really nice. We have a kanban column 'Needs Review' and I've dumped tasks there for PRs, documents, and all kinds of other stuff.