# Example: a documentation review workflow

> **Note: Worked example**
>
> This is a **finished illustration to study**, not a template. It uses the [review request template](https://docs.redaction-technique.org/en/toolkit/documentation-review-request-template/) and [technical review checklist](https://docs.redaction-technique.org/en/toolkit/technical-review-checklist/) as its actual tools.

## The scenario

A new feature ships. The writer has drafted a new task article documenting it, and it needs to go out with the release.

## The workflow

```mermaid
%%{init: {"flowchart": {"curve": "basis"}, "themeVariables": {"fontFamily": "IBM Plex Sans Variable, sans-serif"}}}%%
flowchart TD
    accTitle: Two-Pass Documentation Review Workflow
    accDescr: Structured progression showing separated technical and editorial review passes before publication.

    A["1. Self-review<br/>(Author quality checklist)"] --> B["2. Technical review<br/>(Engineer: Is it accurate?)"]
    B --> C["3. Author addresses feedback<br/>(Resolve blocking comments)"]
    C --> D["4. Editorial pass<br/>(Editor: Is it clear & consistent?)"]
    D --> E["5. Release-readiness check<br/>(Navigation, build & translation)"]
    E --> F["6. Publish alongside feature"]

    classDef step fill:#f1f5f9,stroke:#64748b,stroke-width:1.5px,color:#0f172a,font-weight:500
    classDef pass fill:#e2e8f0,stroke:#3b82f6,stroke-width:1.5px,color:#1e293b,font-weight:600

    class A,C,E step
    class B,D,F pass

    linkStyle default stroke:#64748b,stroke-width:1.5px
```

1. **Self-review first.** The writer runs the [documentation quality checklist](https://docs.redaction-technique.org/en/toolkit/documentation-quality-checklist/) against their own draft before asking anyone else to look at it — catching the obvious issues here is cheaper than a reviewer catching them.

2. **Technical review.** The writer sends a [review request](https://docs.redaction-technique.org/en/toolkit/documentation-review-request-template/) to the engineer who built the feature, scoped explicitly: *"Confirm the steps still match the shipped UI — I'm not asking about wording."* The engineer works through the [technical review checklist](https://docs.redaction-technique.org/en/toolkit/technical-review-checklist/) and leaves blocking comments only on genuine inaccuracies.

3. **Author addresses feedback.** Every blocking comment gets a fix or a reply explaining why it doesn't apply. Non-blocking suggestions are triaged — some taken, some explicitly declined with a reason.

4. **Editorial pass.** A second reviewer — or the same writer, after time away from the draft — checks structure, tone, and consistency with the rest of the site. This pass explicitly does *not* re-litigate technical accuracy; that was step 2's job.

5. **Release-readiness check.** Before the feature ships, the [release readiness checklist](https://docs.redaction-technique.org/en/toolkit/release-readiness-checklist/) confirms the new article is linked from navigation, builds cleanly, and (if applicable) has a translation plan.

6. **Publish alongside the feature**, not after it — see [integrating documentation into development](https://docs.redaction-technique.org/en/tech-writing-process/integrating-documentation-into-development/).

## Why the review is split into two passes

Technical review and editorial review ask fundamentally different questions — "is this true?" versus "is this clear?" — and asking one reviewer to hold both hats at once tends to produce a review that does neither well. Splitting the passes also means feedback doesn't collide: an engineer's technical correction won't get lost among a dozen wording nitpicks, and vice versa.

---

Source: https://docs.redaction-technique.org/en/toolkit/example-review-workflow/