Dataset: Issues & Pull Requests
Entity: Pull Requests
Field ID: merged_by_username
Type: Text
Description: The username of the person who merged the pull request. Note that usernames are app-specific.
Source: App
Transformation logic: N/A
From: |
|
Github (PRs, Issues) |
|
Gitlab (PRs, Issues) |
|
Bitbucket (PRs) |
|
Azure DevOps (PRs, Issues) |
|
JIRA (Issues) | N/A |
ClickUp (Issues) | N/A |
Trello (Issues) | N/A |
Reporting Use Cases
The Merged By
field identifies who performed the final action of merging a pull request, making it crucial for understanding your deployment process and auditing your release pipeline. As a text field, it is most often used for filtering and as a dimension to analyze merge responsibilities.
Filtering and Auditing: You can easily track merge activities and ensure compliance with your internal policies.
Track a Team's Merges: If you have a dedicated release team, you can create a report of all merges performed by them using a filter like
Merged By equals any of "release-manager-1,release-manager-2"
.Personal Activity: Use the is me operator to create a widget that shows all the pull requests you have personally merged.
Exclude Automated Merges: If you use bots to automatically merge pull requests (e.g., Dependabot), you can easily exclude them from your reports to focus on human-led activity with a filter like
Merged By !~ "bot"
.
Reporting on Merge Responsibility: Using
Merged By
as a dimension helps visualize who is responsible for merging code.A bar or pie chart with
Merged By
as the dimension andCOUNT()
as the metric can quickly identify who the primary "gatekeepers" of your codebase are. This can highlight if merge responsibilities are concentrated on a few key individuals, which could represent a process bottleneck.
Advanced Metrics: You can use this field within aggregations to get a higher-level view of your merge process.
Number of Mergers: A KPI with the custom formula
COUNT_DISTINCT(merged_by_username)
will tell you how many unique individuals are merging pull requests. A low number indicates a centralized release process, while a high number suggests a more decentralized, team-based approach.