The Distributions view can show meaningful data right away if your team uses GitHub labels consistently.
When set up correctly, it breaks down where engineering effort is going like what percentage of work is focused on tech debt, security, new features, or bugs.
To clarify: Teams need to manually create these labels (e.g., “tech debt,” “security,” “new feature,” “bug,” etc.) within their GitHub repositories. Once PRs or issues are labeled accordingly, the Distributions view will automatically categorize and visualize that data.
Where to find it
Go to Allocations → Distributions in the left sidebar
This page gives you a single view of how your team’s work is distributed over time.

How it works
The Distributions page pulls data from all PRs or issues within your selected date range. It groups them by label or type to calculate how much work falls into each category.
Each colored section in the chart represents a different type of work:
-
Bugs: fixes and patches
-
Tech Debt: refactoring or cleanup
-
Security: vulnerability and dependency fixes
-
Enhancements: improvements or new functionality
.png)
You can hover over each segment to see the exact percentage and number of PRs associated with that label.

Date range
Choose the time period you want to analyze — for example, a sprint or week range.
All metrics and charts will refresh automatically as you adjust the dates.

Repository filter
Select one or multiple repositories to narrow your view.
This helps you isolate work across different codebases or projects.

User filter
Filter results by a specific team member to see where their work was allocated.
This view is helpful for understanding workload balance or individual focus areas.

Toggle chart type
Switch between two visualization styles:
- Donut Chart: shows percentage breakdowns by category
.png)
- Bar Chart: shows changes in distribution over time

Use whichever view best fits your reporting needs.
GitHub / Jira toggle
Switch between GitHub and Jira to control the data source.
-
GitHub: categorizes work by pull request labels
-
Jira: categorizes by issue types
Interpreting the data
Each slice of the chart represents a category of work. For example:
-
A large Bugs section means the team spent most of their time fixing issues.
-
A higher Tech Debt share could mean time went into refactoring or cleanup.
-
A noticeable Security section shows patches, audits, or dependency updates.
-
More New Features indicates progress toward roadmap or sprint goals.
These distributions help you see whether the team’s focus matches expectations.
Pull Request Table
When you scroll below the chart, you’ll see a detailed list of pull requests that make up the data shown in your distribution.
This table gives you a deeper look at what kind of work happened, where, and by whom.
Each row represents a single PR that was opened or merged during the selected date range.
Here’s what each column means:
Label Name
Shows which category the pull request belongs to, such as Bug, Enhancement, or Release.
These labels come directly from GitHub (or issue types in Jira).
If a PR has multiple labels, it contributes to multiple categories in your chart.
Title
Displays the name of the pull request exactly as written in GitHub.
This helps you understand the purpose of the change — for example, “Fix grading review comments” or “Update migration script.”
Repository
Indicates which repository the PR originated from.
Useful for teams managing multiple codebases, as it shows where work is concentrated.
Author
Identifies who opened or merged the pull request.
Each entry includes the contributor’s avatar for quick recognition, so you can easily track individual activity.
PR Size
Shows how many lines of code were added (+) and removed (–) in the pull request.
This helps you spot large changes that may need extra review attention or smaller fixes that were merged quickly.

How to interact with this section
-
You can sort by any column (e.g., Label Name, Author, or PR Size) to reorder the list and highlight specific trends.
-
The search bar lets you quickly find a PR by title or keyword.
-
Use the pagination controls at the bottom (Previous / Next) to navigate across pages of results if your timeframe includes many PRs.
Why it matters
This section connects the high-level chart data to the actual engineering work behind it.
While the chart shows how much time went into each type of work, this list shows exactly which pull requests drove those numbers.
You can use it to:
-
Review work patterns across team members and repositories.
-
Identify large PRs that might need a follow-up or review.
-
Verify that all PRs are labeled correctly, so your distribution data stays accurate.
-
Understand what kind of work dominated the week — bug fixes, refactors, or new features.
Troubleshooting
-
Percentages don’t add up neatly → Normal. A single PR can have multiple labels.
-
No data showing → Expand your date range or confirm repos are selected.
-
Chart not switching → Refresh your browser and check the toggle.
-
Missing PR sizes → Make sure your GitHub token has access to read diffs.
-
Too many “Unlabeled” items → Check if your team is consistently applying labels or issue types.