Managing Reviewboard

---
name: managing-reviewboard
description: |
  Use when working with Reviewboard — review Board code review management
  including review requests, diff management, review groups, and repository
  configuration. Use when managing Review Board review workflows, configuring
  review groups, and automating review request assignment.
connection_type: reviewboard
preload: false
---

# Managing Review Board

## Overview

Manage Review Board review workflows, including review request creation, diff management, reviewer group configuration, and review completion policies.

## Key Capabilities

- Create and manage review requests with multi-revision diffs
- Configure review groups and default reviewer assignment
- Manage repository integrations and diff processing
- Set up review completion requirements
- Configure extensions for custom workflow automation
- Track review request status and turnaround metrics

## Workflow

### 1 — Review Group Configuration

```
REVIEW GROUPS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Groups:
    Name                | Members          | Default for Repository
    ────────────────────┼──────────────────┼───────────────────────
    backend-review      | @backend-devs    | backend-service
    frontend-review     | @frontend-devs   | web-app
    security-review     | @security-team   | (all repositories)
    platform-review     | @platform-team   | infrastructure
[ ] Mailing list per group: YES / NO
[ ] Visible to: everyone / members only
[ ] Invite-only: YES / NO
```

### 2 — Default Reviewers

```
DEFAULT REVIEWERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Repository-level defaults:
    Repository: backend-service
    Default people: @tech-lead
    Default groups: backend-review
[ ] File pattern defaults:
    Pattern: /security/**
    Reviewer: security-review group
    Pattern: /api/**
    Reviewer: @api-owner
```

### 3 — Review Completion Policy

```
REVIEW COMPLETION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Ship It required from: ___ reviewers
[ ] All reviewers must respond: YES / NO
[ ] Ship It from group member counts for group: YES / NO
[ ] Allow submitter to close without Ship It: YES / NO
[ ] Require all open issues to be resolved: YES / NO
```

## Common Operations

### List Pending Reviews
Query open review requests awaiting action, filter by group or assignee.

### Diff Comparison
Compare diff revisions within a review request to track changes between iterations.

### Review Metrics
Track Ship It rates, review turnaround time, and reviewer participation.

## Troubleshooting

| Issue | Cause | Fix |
|-------|-------|-----|
| Default reviewer not added | Pattern mismatch | Verify file path patterns in default reviewer config |
| Diff upload fails | Repository not configured | Add repository with correct SCM tool and path |
| Email notifications missing | SMTP not configured | Check Review Board email settings |
| Review request stuck | Missing Ship It | Contact assigned reviewers or reassign |

## Output Format

Present results as a structured report:
```
Managing Reviewboard Report
═══════════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]
```

Target ≤50 lines of output. Use tables for multi-resource comparisons.

## Anti-Hallucination Rules

1. **NEVER assume resource names** — always discover via CLI/API in Phase 1 before referencing in Phase 2.
2. **NEVER fabricate metric names or dimensions** — verify against the service documentation or `--help` output.
3. **NEVER mix CLI commands between service versions** — confirm which version/API you are targeting.
4. **ALWAYS use the discovery → verify → analyze chain** — every resource referenced must have been discovered first.
5. **ALWAYS handle empty results gracefully** — an empty response is valid data, not an error to retry.

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "I'll skip discovery and check known resources" | Always run Phase 1 discovery first | Resource names change, new resources appear — assumed names cause errors |
| "The user only asked for a quick check" | Follow the full discovery → analysis flow | Quick checks miss critical issues; structured analysis catches silent failures |
| "Default configuration is probably fine" | Audit configuration explicitly | Defaults often leave logging, security, and optimization features disabled |
| "Metrics aren't needed for this" | Always check relevant metrics when available | API/CLI responses show current state; metrics reveal trends and intermittent issues |
| "I don't have access to that" | Try the command and report the actual error | Assumed permission failures prevent useful investigation; actual errors are informative |