Git Activity: Metrics & Filters Glossary

The WIP filter in Git Activity shows engineering tasks (branches) that are currently in progress – for example, branches in an active state that have not yet been merged or closed.

Use this view to validate whether the team is working on the right things during an iteration:

• Confirm that most active branches are tied to the iteration’s planned work.
• See if the team is spread too thin across many concurrent branches.
• Spot branches that have been “active” for a long time and may be stuck.

Draft pull requests are used to signal that work is not yet ready for review or merge. They allow developers to push code, run CI, and request early feedback without impacting review metrics or triggering review alerts.

How LinearB treats draft PRs

• Cycle Time: Draft PRs are excluded from cycle time calculations.
• Stage time: Time while a PR is in draft is attributed to Coding Time, not Pickup / Review time.
• Notifications: Draft PRs do not trigger “Review Request Hanging” or “Review Too Long” alerts until they are made ready for review.
• WorkerB: Team alerts and personal review alerts ignore draft PRs until they leave draft status.

Configuring draft PR detection

LinearB automatically detects draft pull requests using the Git provider’s native draft status (where available). If your team uses naming cues instead of the native status, you can also configure title-based detection.

Why it matters

• Keeps cycle time and review metrics clean by excluding work that isn’t truly ready for review.
• Prevents false “review hanging” alerts while a PR is intentionally in draft.
• Encourages teams to use draft status consistently so metrics reflect reality.

For a deeper walkthrough of behavior across metrics, alerts, and providers, see
Draft pull requests in LinearB .

Branches are mutable: their state changes over time (Active → Stale → Merged → Active, etc.). The Point in History capability lets you see a snapshot of branch states on a specific past date.

When you select a date in the past, LinearB shows:

• The state each branch had on that date.
• The number of commits and changes up to that date.
• Work breakdown and last update time as of that date.

Note: The current state of the branch may be very different from what you see at the historical snapshot.

Done in <Iteration> shows all tasks (branches) that were completed during the iteration.

Because teams define “done” differently, this view includes branches that were either:

• Merged, or
• Deployed

Typical filter logic:

• State: Merged OR Deployed
• Last Update: <First day of the iteration> – <Last day of the iteration>

Use this to see what the team completed in the iteration and compare to the plan during retros.

Carryover from <Iteration> shows tasks that were not completed in the iteration and were still active after it ended.

Typical filter logic:

• Point in History: last day of the iteration
• State: Active
• Last Update: <First day of the iteration> – <Last day of the iteration>

Use this to see what slipped out of the iteration and understand where goals were missed.

Merged in <Iteration> shows all PRs that were merged during a specific iteration.

Typical filter logic:

• PR State: Merged
• Merged between: <First day of the iteration> – <Last day of the iteration>

Updated in <Iteration> shows all PRs that had activity during the iteration. “Update” includes:

• New reviews
• New comments
• Additional commits
• Merge events
• Close events

Typical filter logic:

• PR State: All
• Last Update: <First day of the iteration> – <Last day of the iteration>

High interaction PRs are PRs with a large number of comments in the review cycle. This may signal:

• Low code quality or problematic coding approaches that trigger many review comments.
• Fundamental disagreements between author and reviewer that may require manager mediation.

Typical filter logic:

• Comment Count: Large (10+ comments)

High Rework refers to branches with a high volume of code changes and a high proportion of rework.

Rework is influenced by both:

• Total code changes introduced in the branch.
• Changes to existing code that was added in the last ~3 weeks.

More changes, especially to recently added code, increase rework.

Typical filter logic:

• State: Active (updated within the last 7 days)
• Rework: High (> 30%)
• Changes: Large (> 300 lines)

High Risk work highlights branches where risk is elevated due to large change volume and a high proportion of changes to existing code.

Use this to identify branches that need extra review or testing.

Typical filter logic:

• State: Active (updated within the last 7 days)
• New Work: Small (< 50% of changes)
• Changes: Large (> 300 lines)

Lightning PRs are PRs that were merged very shortly after review began. While speed can be good, very fast reviews may indicate superficial review and potential quality risk.

Typical filter logic:

• PR State: Merged
• Review Time: 0–20 minutes

Long living PRs are PRs that were created a long time ago and still have not been merged. They may indicate work waiting too long for review or an extended review cycle.

Typical filter logic:

• PR State: Initiated or In Review
• Created before: ~30 days ago

These PRs should be prioritized to avoid stalled work and excessive cycle time.

Merged without review refers to PRs that were merged either:

• With no review at all, or
• With only self-review by the author.

This significantly increases the risk of bugs or broken code entering production. Teams should aim to reduce this pattern as much as possible.

Review request hanging highlights PRs where a review was requested but not started within a reasonable time window.

These PRs delay cycle time and can become a bottleneck in the development pipeline.

Typical behavior:

• PR was created more than ~3 days ago.
• No review has started (no review comments).

The Releases report is available from the Activity tab by selecting Releases, or by clicking a data point in the Deploy Frequency graph.

By default, the view shows releases from the last 30 days. You can adjust the range using the Event Dates filter.

You can filter releases by:

• Team – via the team dropdown or filter menu.
• Contributors – branches where selected developers contributed code.
• Repositories – releases to a specific repo (click a repo name to filter).
• Services – if you’ve configured services in LinearB.
• Stages – release stages (e.g., Release, or additional stages when multi-stage detection is configured).
• Event Dates – date the release occurred.

Common columns in the Releases table:

• Releases – release name.
• Reference – git reference (SHA / branch / tag). Clicking copies it.
• Repositories – repo name (click to filter by that repo).
• Published At – date and time of the release.
• Stage – deployment stage; click to filter by stage.
• Connected branches – number of branches bound to this release (hover to see names; click to view in LinearB).
• Services – related service name, if configured.
• Release Detection – how the release was detected (e.g., deployment API, tag, or merge-commit based detection).

It’s normal for the total number of releases listed here to be higher than what you see in the Deploy Frequency report, since some releases may not be linked to reportable branches or may be on repos excluded from reporting.