Document PR best practices: checklists, titles, communication, conflict resolution, screenshots

[bobleesj]

Context

Based on electronmicroscopy/quantem#179 — this PR is a good example of where clearer PR conventions would help both author and reviewer.

What to document

Add a section to README.md covering PR best practices:

1. How to use checklists — author checklist (tests pass, docs updated, no unrelated changes) and reviewer checklist (implementation matches intent, tests are appropriate). When to use - [x] vs - [ ].

2. How to write an effective PR title — short, specific, imperative. Describe the what, not the how. Example: "Add _CellView indexing to Vector" not "Updated vector.py with new helper subclass".

3. How to communicate between Author and Reviewer — respond to every comment, distinguish between "fixed" vs "out of scope" vs "will address in follow-up". Use threads. Don't leave comments unresolved.

4. How to resolve conflicts — when author and reviewer disagree on approach, escalate to the weekly meeting or a GitHub issue, don't block the PR indefinitely.

5. How to display code's results — attach screenshots of input/output (before and after). For API changes, include the API design in the PR body showing usage examples. Show what the user types and what they get back.

6. Use AI to check quality — before submitting, use an LLM to review your own PR for clarity, correctness, and completeness. Double-check docstrings, error messages, and test coverage.

7. API design in PRs — for any PR that adds or changes public API, the PR body must include:

   • The proposed API (function signatures, usage examples)
   • Screenshots or notebook output showing inputs and outputs
   • Before/after comparison if modifying existing behavior

Owner

@wwmills to lead this. @bobleesj available for review.

Reference

See the current "Guidelines" and "Common mistakes to avoid" sections in README.md for existing PR guidance that this would extend.