> ## Documentation Index
> Fetch the complete documentation index at: https://docs.weaveos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Comment resolution rate

> Percentage of suggestion comments the author addressed with a later commit or a clear reply

## How it works

Comment resolution rate measures what percentage of suggestion comments the PR author addressed, either with a later commit or, when no later commit addresses the comment, with a clear reply in the thread. This metric indicates how actionable and effective code review feedback is, and how responsive authors are to reviewer suggestions.

Higher resolution rates indicate:

* Actionable, specific review feedback
* Authors responsive to reviewer suggestions
* Effective collaboration during code review
* Aligned understanding of code quality standards

## Calculation

The rate is calculated by comparing addressed suggestions to total suggestions.

**Formula:**

```
Resolution rate = (Addressed suggestions / Total suggestions) × 100
```

### What counts as actionable

Only comments that could reasonably result in code changes:

* **Suggestions:** Proposed improvements or changes, including minor style or naming feedback

### What's excluded

Comments that don't require code changes:

* **Questions:** Clarification requests
* **Praise:** Positive feedback
* **Discussion:** General comments or context

### How resolution is detected

Weave uses AI to determine if a comment was resolved:

1. **Identify comment:** Extract the reviewer's feedback
2. **Find subsequent commits:** Look at commits after the comment
3. **Analyze changes:** Check if commits address the specific feedback
4. **Determine resolution:** AI evaluates if the concern was fully addressed
5. **Fall back to the conversation:** If no later commit addresses the comment, Weave checks whether the thread clearly addressed, deferred, or dismissed the concern

<Note>
  Resolution is based on code changes and the conversation, not a thread's resolved status. Marking a thread resolved on the pull request doesn't count as addressed on its own.
</Note>

See [comment resolution](/metrics/comment-resolution) for detailed resolution detection methodology.

## Why it matters

Comment resolution rate reflects:

* **Review effectiveness:** Are reviews producing helpful, actionable feedback?
* **Author responsiveness:** Do authors address reviewer concerns?
* **Team dynamics:** Is there good collaboration and trust?
* **Quality standards:** Are expectations aligned?

### Interpreting the numbers

**80-100% (excellent):**

* High-quality, actionable review feedback
* Authors addressing nearly all suggestions
* Strong collaboration and trust

**60-80% (good):**

* Most feedback is addressed
* Some comments may be discussed and deferred
* Healthy balance of standards and pragmatism

**40-60% (moderate):**

* Significant feedback not addressed
* Possible communication gaps
* May indicate unclear expectations

**Below 40% (concerning):**

* Most feedback ignored or not acted upon
* Review process may not be effective
* Possible trust or communication issues

## Common patterns

### High resolution rate (90%+)

**Positive interpretation:**

* Excellent, actionable feedback
* Authors committed to addressing concerns
* Strong code quality culture

**Potential concerns:**

* Reviewers only commenting on trivial issues
* Authors over-complying without pushback
* Missing opportunities for design discussions

### Low resolution rate (50%)

**Possible causes:**

* Reviewers commenting on out-of-scope items
* Authors deferring changes to future PRs
* Philosophical disagreements
* Comments are questions, not suggestions

**When it's acceptable:**

* Complex PRs with design tradeoff discussions
* Experimental or exploratory code
* Comments suggesting future improvements

## Improving resolution rate

### For reviewers

1. **Make feedback actionable:**
   * Be specific about what to change
   * Provide examples or suggestions
   * Distinguish between blocking and non-blocking comments

2. **Scope feedback appropriately:**
   * Focus on the PR's stated goal
   * Don't request unrelated improvements
   * Tag "out of scope" comments clearly

3. **Use comment intent tags:**
   * Mark suggestions vs. questions
   * Indicate blocking vs. non-blocking feedback
   * Be clear about expectations

### For authors

1. **Respond to all comments:**
   * Address each piece of feedback
   * Explain if you disagree or defer changes
   * Reply in the thread when you handle feedback without a code change

2. **Update code based on feedback:**
   * Make requested changes in follow-up commits
   * Reference comments in commit messages
   * Push all fixes together when possible

3. **Communicate deferments:**
   * Explain why changes are deferred
   * Create follow-up tickets for future work
   * Get reviewer agreement on deferments

### For teams

1. **Align on standards:**
   * Document coding conventions
   * Define "blocking" vs. "nice to have"
   * Create PR templates and checklists

2. **Foster healthy communication:**
   * Encourage constructive feedback
   * Make it safe to disagree
   * Focus on learning and improvement

3. **Review the review process:**
   * Track resolution rate trends
   * Discuss patterns in retrospectives
   * Adjust practices based on data

<Note>
  Resolution rate should be balanced with other metrics. Very high rates (99%+) might indicate reviewers avoiding meaningful feedback. Very low rates (30%) suggest broken review process.
</Note>

## Technical details

<AccordionGroup>
  <Accordion icon="robot" title="How does AI detect comment resolution?">
    The AI resolution detector:

    1. **Analyzes comment text:** Understands the reviewer's specific concern
    2. **Examines commits:** Reviews all commits made after the comment
    3. **Compares changes:** Checks if file/line changes address the feedback
    4. **Assigns confidence:** Rates resolution as very high, high, medium, or low confidence
    5. **Considers context:** Looks at thread replies and discussion

    Medium, high, and very high confidence resolutions count as addressed.
  </Accordion>

  <Accordion icon="filter" title="Which comments are included?">
    **Included:**

    * Suggestion comments (proposed improvements)
    * Comments on merged PRs only

    **Excluded:**

    * Question comments
    * Praise comments
    * Comments on abandoned/closed PRs
    * Comments from AI code review tools, unless you group by AI tool (each group then shows only that tool's comments)
  </Accordion>

  <Accordion icon="circle-question" title="Why does a comment I resolved on the pull request show as not addressed?">
    A thread's resolved status isn't used. A suggestion counts as addressed when a later commit makes the requested change, or when no later commit addresses it and the thread clearly addresses, defers, or dismisses it.

    Changes to files Weave excludes from analysis aren't examined, so a fix made only in those files isn't detected. This includes generated code, lockfiles, and some docs and config files (for example `.md`, `.yml`, `.json`, and `.tfvars`).

    If a verdict is wrong, users with edit access can override it from the chart's drill-down using the **Addressed** toggle.
  </Accordion>

  <Accordion icon="calendar" title="How is the rate aggregated?">
    Resolution rate is calculated as a percentage across all comments:

    * **Per PR:** Percentage of comments resolved in that PR
    * **Per engineer:** Percentage of comments resolved across all their PRs
    * **Per team/org:** Percentage of all comments resolved

    The metric uses the total count of resolved vs. unresolved comments, not an average of per-PR rates.
  </Accordion>

  <Accordion icon="chart-line" title="What data sources are used?">
    Comment resolution rate uses:

    * **Git repository data:** PR reviews, comments, and commits
    * **AI analysis:** LLM-powered resolution detection
    * **Supported platforms:** GitHub, GitLab, Bitbucket
  </Accordion>
</AccordionGroup>

## Related metrics

* **[Comment resolution](/metrics/comment-resolution):** Detailed drill-down of which comments were resolved
* **[Review cycles](/metrics/review-cycles):** Number of review rounds per PR
* **[Review quality](/metrics/review-quality):** How thorough and helpful reviews are
* **[Code review efficiency index](/metrics/review-efficiency-index):** Composite review effectiveness metric


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.