# Code Review - Notes

1. If you have not already, *please* watch the video I shared on Teams
- https://www.youtube.com/watch?v=PJjmw9TRB7s
- This is not a definitive guide, but I think it provides at least a very solid foundation to build from
- Other resources out there too, do some homework :)
- e.g.) https://google.github.io/eng-practices/review/reviewer/
2. Remember *why* we're reviewing code in the first place
- Code quality is important, but experience/data show that code reviews do not do particularly well in this department, so don't obsess!
- Design decisions *are* important!
- Challenge everything! Come up with alternatives, weigh the pros/cons
- Understand *why* decisions were made in the first place
- Be aware of any side effects of the proposed changes, either within the project or in dependent packages
3. In order to make code review as easy as possible on ourselves, we need to reduce (or ideally, eliminate) ambiguity from the process
- There should be a styling guide, and as much should be verified automatically (e.g. in CI) as possible, in order to remove the human element
- We need to review and improve CI
- It is still not checking *all* of the things it should be...
- We should spend some serious time on `CONTRIBUTORS.md` and make it into a high-quality document to which we can point people
- This can give context and required information/resources for contributing, in order to increase the initial quality of PRs on average
- We can provide patterns/conventions/naming/style guides in order to make decisions easier for contributors
- A guide for writing good documentation would be awesome to have
4. Another thing that will probably help is using `CODEOWNERS`
- There are parts of the code base that we do/don't understand, none of us grok it entirely
- Would be nice to know who to go to for a particular driver! Makes reviewing easier as well