{"id":"doc_AAkfSAASSbeiTPNxrXq5LuAid7gB","version":1,"filename":"code-review-guidelines.md","description":"Code review exists to catch bugs, share knowledge, and maintain code quality. It does not exist to relitigate architectural decisions that were made six ...","title":"Code Review Guidelines","content":"# Code Review Guidelines\n\n## Purpose\n\nCode review exists to catch bugs, share knowledge, and maintain code quality. It does not exist to relitigate architectural decisions that were made six months ago.\n\n## Process\n\n1. Open a pull request\n2. Assign at least one reviewer\n3. Reviewer reviews within 24 hours (48 hours if it's a large PR, 1 week if it's a PR from the intern)\n4. Author addresses feedback\n5. Reviewer approves\n6. Author merges\n\n## What to Look For\n\n- Does the code work?\n- Is it readable?\n- Are there tests? (Aspirational at TomlTech, but we're trying)\n- Are there obvious security issues?\n- Does it follow the existing patterns in the codebase, even if those patterns are questionable?\n\n## What Not to Do\n\n- Do not rewrite the entire PR in your review comments\n- Do not leave \"nit\" comments on code that is functionally correct and readable\n- Do not request changes because you would have done it differently\n- Do not approve without reading the code (we know you do this, please stop)\n- Do not leave the comment \"looks good to me\" on a PR that deletes the authentication system\n\n## Style\n\nWe use Rubocop with the default configuration plus 14 custom rules that nobody remembers adding. If Rubocop passes, don't argue about style. If you disagree with Rubocop, open a PR to change the Rubocop config. Nobody has ever done this because it requires understanding the Rubocop config, and the Rubocop config is 400 lines long.\n\n## Turnaround Time\n\nReviews should be completed within 24 hours. If a review is not completed within 48 hours, the author may merge without review. This rule was added after a PR sat open for 3 weeks and the branch diverged so far from main that the merge conflict was larger than the original PR.\n\n## The \"Gary Rule\"\n\nNamed after a former employee. If a PR introduces a gem dependency, the reviewer must verify that:\n1. The gem is actively maintained\n2. The gem has more than 3 downloads\n3. The gem author is not named Gary\n","url":"/tomltech/internal-processes/code-review-guidelines.md.json","account":{"id":"acct_Xt3PcFnov6BzMDisOIF8U7jQL7ue","name":"TomlTech Consulting Group","url":"/tomltech.json","slug":"tomltech"},"tags":[],"project":{"id":"proj_QDHlxfH0sFcc9jHG71v1LU1Dm3D6","name":"Internal Processes","url":"/tomltech/internal-processes.json","slug":"internal-processes"},"locked_at":null,"locked_by":null,"uploaded_by":{"id":"user_LcwII51B5RTE3CqBgc6L9Sns0iv9","username":"deepak_tomltech","display_name":"Deepak Iyer"},"uploaded_at":"2026-01-03T00:00:00Z"}