Copilot Addressed Rate: Measure Feedback and Pull Request Approval Separately

On November 5, 2026, GitHub added Copilot code review feedback metrics to its repository-level usage reports. The new addressed rate tracks action on evaluated comments. Teams should report that separately from pull request approval.

Genuine GitQuick public showcase screenshot captured November 8, 2026. The three cards use different conditions; the middle card also uses a different denominator.

What GitHub shipped

The new copilot_code_review object appears in enterprise and organization repos-1-day reports. Divide total_comments_addressed by total_comments_evaluated to calculate addressed rate. If the denominator is zero, report no evaluated comments rather than a percentage.

Addressed includes applying a suggestion, delegating a fix to Copilot, editing code, or promising a fix in a later PR. GitHub explicitly includes “replying that the fix will come in a later pull request.” That is broader than completed remediation.

Comments count on the PR's merge day. Bot-authored PR comments are usually excluded from evaluation. A separate count, total_merged_no_human_change_request_after_review, includes bot PRs and records merges without a human change request after Copilot's first review.

These are feedback and workflow observations. Neither metric establishes that a person approved the change.

Why feedback, approval, and merge permission need separate checks

The practical pain is ambiguity. An author needs to know what to change. A maintainer needs to know who accepted the result. A reporting system needs an event it can count consistently.

In an October 6 GitHub Community report, user glen-84 described a Copilot overview that requested action but listed no findings: “There is nothing to act on.” This is one reported experience, not a prevalence estimate. It illustrates why prose, findings, and recorded review state should not be treated as interchangeable.

GitHub's review decision reference defines Approve as “Signals that the changes are ready to merge.” A submitted Comment review gives feedback without that explicit decision. Request changes records a different decision again.

Merge permission adds another question. Which approvals count depends on repository rules and reviewer eligibility. GitHub documents that approvals can be dismissed after code changes when stale-review dismissal is enabled. An approval count alone therefore cannot reconstruct whether the final commit satisfied the applicable rules.

How to measure merged pull requests without approval

GitQuick's Metrics view exposes Merged Without Review, Merged Without Approval, and Reviewed and Approved together, so teams can inspect this distinction in their own runs. Its public showcase exposes the same coverage counts; it does not currently import Copilot's new addressed-rate reports.

Merged Without Review counts merged PRs with zero recorded review events. Merged Without Approval counts merged PRs with zero recorded APPROVED reviews. Both percentages divide by the number of merged PRs in the selected run.

An approval is itself a review. Consequently, merges without review are a subset of merges without approval. A PR can have several comment reviews and still have no approval.

Reviewed and Approved uses a narrower denominator: merged PRs that received at least one review. Its numerator is the portion of those PRs with an approval. It is not the approval percentage across every merged PR, and it is not a human-only measure.

The implementation aggregates stored review states. It does not reconstruct the review-policy state at the exact merge moment or verify that an approval applied to the final code. Treat these counts as a way to select PRs for inspection, not an audit verdict.

What the live showcase reveals

The public organization list contained 21 organizations when checked on November 8. These three examples use each organization's latest available snapshot, with UTC dates shown below. The run selects PRs created within its analysis window; the merged denominator is the merged subset of those selected PRs, not every merge occurring during those calendar dates.

All windows are in 2026. Snapshot run IDs are 622, 625, and 629 respectively. These are examples of different recorded workflows, not organization rankings or observations of Copilot effectiveness.

AWS illustrates the denominator issue. Its Reviewed and Approved card shows 2,642 approvals among 2,749 reviewed merged PRs, or 96.11%. Its Merged Without Approval card shows 446 of all 3,088 merged PRs, or 14.44%. Both can be correct because the first calculation excludes merges with no reviews.

For GitHub's public repositories, the larger gap identifies a different investigation: which selected merges had review activity without an approval state? It does not establish that reviews were inadequate or that maintainers violated policy.

A practical weekly approval check

Start with one repository and its intended approval policy. Record the target branch, analysis window, and merged denominator. Do not combine repositories with different approval expectations into a single compliance claim.

Inspect a small sample of PRs with reviews but no recorded approval. Read the timeline, reviewer identities, final commit, and relevant rules. Classify the explanation: an intentional exception, feedback without sign-off, dismissed approval, or incomplete evidence. Keep unresolved cases unresolved.

If you also collect Copilot addressed rate, retain its evaluated-comment count and merge-day reporting basis beside it. Do not join a comment percentage to a PR percentage as if they describe the same population. Track deferred fixes separately so follow-up work remains visible.

After a process change, compare the same repository and branch scope over comparable windows. Look for fewer unexplained approval gaps, then check whether waiting time increased. A useful review process needs clear decisions as well as timely feedback.

Takeaway

Keep three questions explicit: Was feedback acted on? Was approval recorded? Did the final merge meet the repository's rules? Each needs its own evidence.

For related guidance, read how review metrics depend on coverage and eligible samples and what review events can tell you.

Inspect the public snapshots for Apple, AWS, and GitHub, or browse the Showcase. Try GitQuick to inspect review and approval coverage for your organization.

Disclaimer: This article uses public GitHub metadata and primary-source documentation checked November 8, 2026. Metadata cannot establish code quality, human verification, policy compliance, or causality. GitQuick is not affiliated with or endorsed by GitHub, Apple, AWS, or other organizations mentioned.