This describes the process I follow to review a pull request

The RubyLA blog offers insights, tutorials, and community updates for Ruby developers in Los Angeles and beyond. Developers can explore Ruby language features, web development frameworks, and best practices for building Ruby applications. Additionally, the blog covers Ruby meetups, events, and job opportunities in the Los Angeles area, fostering collaboration and networking within the local Ruby community.

RUBYLAND

A systematic approach to reviewing pull requests using the journalist's 5 Ws and H framework. The process covers when to review (start of day, between meetings, after submitting your own PR), what to look for based on PR intent, understanding your motivation as a reviewer, considering the author and audience, and a specific reading order: title/description first, then tests (test-driven review), followed by implementation alphabetically, and finally a big-picture pass to verify goals and overall structure.

How I Read A Pull Request

Start reading tests.
There are no tests.
PR Rejected.

Reading the tests first is clever. I am going to try that.

great tips, although after lunch I can basically do nothing