Skip to content

Add PR Review Guide for Contributors #80

@josecelano

Description

@josecelano

Add PR Review Guide for Contributors

📋 Issue Information

🎯 Problem Statement

Code reviews currently lack a systematic guide for reviewers. This has allowed issues like architectural violations (#75 - config module in wrong layer) to be merged without detection.

Reviewers need:

  • A quick reference guide for important review aspects
  • Clear red flags to watch for
  • Consistent review criteria across all PRs

Without a standardized guide, we risk:

  • Merging code that violates architectural principles
  • Inconsistent review quality
  • Missing important quality aspects
  • Technical debt accumulation

💡 Proposed Solution

Create a concise PR review guide at docs/contributing/pr-review-guide.md that consolidates project quality standards for reviewers, including a comprehensive checklist, quick red flags section, and guidance on providing constructive feedback.

📝 Implementation Plan

See detailed specification: docs/issues/add-pr-review-guide.md

✅ Acceptance Criteria

Note for Contributors: These criteria define what the PR reviewer will check. Use this as your pre-review checklist before submitting the PR to minimize back-and-forth iterations.

  • Document created at docs/contributing/pr-review-guide.md
  • Comprehensive quality standards checklist included
  • Checklist covers: branching, commits, code quality, testing, documentation
  • Quick red flags section for common violations
  • Example feedback showing how to reference docs
  • Guidance on when to request changes vs. comment vs. approve
  • Issue templates updated with contributor note about acceptance criteria
  • docs/issues/SPECIFICATION-TEMPLATE.md updated with pre-review checklist note
  • docs/issues/GITHUB-ISSUE-TEMPLATE.md updated with pre-review checklist note
  • docs/contributing/roadmap-issues.md updated with "Acceptance Criteria as PR Review Checklist" section
  • Linked from docs/contributing/README.md
  • All linters pass (markdownlint, cspell)
  • Document follows project markdown conventions
  • Clearly states it's a living document that will evolve

🏷️ Labels

documentation, enhancement, code-review, contributing-guide

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions