Kellen's Code Review process:

1. Open up code review link or linked commits in a browser.
2. Check out the branch on my local.
3. Go line by line through the modified code looking for:

- Functionality checks - Is the code doing what it's supposed to? This involves verifying that the developer read and correctly understood the intent of the feature and wrote code that accomplishes the desired functionality.
- Code organization - Is the code organized in a way that makes sense? Example: We want page templates and template parts to be mostly markup and for logic to exist in functions/methods in separate files rather than having everything commingled together.
- Functions & hooks - Are safe and correct functions & hooks being used? Example: using PHP's current() to get the value of the first element in an array behaves differently in PHP7 than it did in older versions and that can introduce bugs - it's safer to use $array[0] syntax instead.
- Sanity checks - Are sanity checks in place to verify data is what we expect it to be at any given point?
- Sanitization - Is data from user input or other external sources being sanitized before we work with it or store it?
- Escaping - Is data being escaped using the correct functions before it's output?
- Internationalization - Are all string literals in the code translatable?
- Performance - Is the code written in the most optimal way so that it will load quickly? This often involves using less computationally expensive ways of accomplishing things and implementing caching.
- Inline documentation - Did the dev include inline documentation to explain things that may not be immediately obvious? Self-documenting code is also acceptable, and encouraged.
- DocBlocks - Are DocBlocks present and complete for all functions & methods?
- Formatting and readability - Does the code meet the WDS coding standards and in general, is it formatted well and easily readable?

4. Review the feature locally/on lab (if applicable) and verify the functionality works as intended. Try to use the feature in various ways and ensure it doesn't break, or fails gracefully.
5. Leave comments in GitHub/Beanstalk with what needs to be changed (or what was done well!) and assign back to the developer to make those changes if necessary.
6. If no changes are needed, merge the branch in. Document on the task/issue, stating that it's complete and assign to the PM.