Dataset: Issues & Pull Requests
Entity: Pull Requests
Field ID: resolved_issue_assignee_usernames
Type: List of text values
Description: The combination of assignees from all resolved issues (via auto-closing keywords), deduplicated and sorted. It is only applicable to pull requests.
Source: Calculated
Transformation logic:
Pull Requests: Aggregate all results of the
assigneesfield from resolved issues. Identical assignees are deduplicated. Resolved issues are issues that are referenced by a resolving pull request.Issues: Not applicable. This field will always be an empty array
[].
From: |
|
Github (PRs, Issues) | Calculated |
Gitlab (PRs, Issues) | Calculated |
Bitbucket (PRs) | Calculated |
Azure DevOps (PRs, Issues) | Calculated |
JIRA | N/A |
ClickUp | N/A |
Trello | N/A |
Reporting Use Cases
The Resolved Issue Assignees field provides a complete list of all individuals assigned to the issues that a pull request resolves. This makes it a powerful tool for analyzing collaboration patterns and understanding who is involved in the end-to-end delivery of a feature, from issue management to code implementation.
Analyzing Cross-Functional Collaboration: This field's primary use is to see if the people implementing the code (the PR authors) are the same people who were assigned to the initial issue.
You can create a custom formula dimension to flag pull requests where the work was handed off:
IF(CONTAINS(resolved_issue_assignee_usernames, author_username), "Same Owner", "Handoff"). A high number of "Handoffs" might indicate a process where one team scopes the work and another implements it, or it could highlight inefficiencies.
Reporting on Team-Level Contributions: When you want to credit work to everyone involved in a feature, not just the coder, this field is essential. By using the
FLATTENfunction on this field, you can associate a pull request with everyone who was part of the original issue.To get a full picture of team involvement, you can create a dimension that combines all participants:
FLATTEN(author_username + resolved_issue_assignee_usernames). Using this with aCOUNT()metric would show the total number of pull requests each person was involved in, either as an author or an issue assignee.
Filtering by Issue Ownership: You can create reports on pull requests based on who was responsible for the original issue.
To see all the implementation work that stemmed from issues assigned to a specific product manager, you could use a filter like
Resolved Issue Assignees contains "product.manager".