(i find)the right way to read a PR can differ a lot from project to project. it's not just about context, or syntax, or workflow...
sometimes the best entry point is the PR description or an external ticket. sometimes you need to read the code first to understand the reasoning behind the changes. sometimes the diff itself is fine, but you have to go back several PRs to see how the codebase got into its current state.
i guess like everyone said here, there no right way to do it.
but i enjoy the video and the project, kudos ;)
Great point and that's our takeaway too from talking to many users. We're exploring ways for Stage to possibly tailor the review flow to each specific PR/user preferences. Would love to hear any ideas if you have any!