Review peculiarities

• every monday morning after the briefing is dedicated to reviews (re-reading them and unstacking them)

• reviews should be prioritized by chronology + preference

• attribute reviews to topic experts

• split issues into sub-issues whenever possible

• make small PRs when possible

• if a PR is big, it should be reviewable file by file thanks to documentation and author's presentation

• discuss with the author

• give feedback on review quality when problematic

• mark critical/prioritary issues/PRs as such

• avoid "change requested" when possible, prefer inline code propositions to avoid back-forth

• consider review externalization (TODO)