Dataset: Issues & Pull Requests
Entity: Issues
Field ID: resolving_pr_project_names
Type: List of text values
Description: The list of project names from all resolving PRs (via auto-closing keywords), deduplicated and sorted. It is only applicable to issues.
Source: Calculated
Transformation logic:
Pull Requests: Not applicable. This field will always be an empty array
[].Issues: Aggregate all results of the
projectfield from resolving pull requests. Identical projects are deduplicated.
From: |
|
Github (PRs, Issues) | Calculated |
Gitlab (PRs, Issues) | Calculated |
Bitbucket (PRs) | N/A |
Azure DevOps (PRs, Issues) | Calculated |
JIRA (Issues) | Calculated |
ClickUp (Issues) | Calculated |
Trello (Issues) | Calculated |
Reporting Use Cases
The Resolving PR Project Names field is a crucial attribute for understanding your software architecture and development patterns, as it lists all the repositories that were modified to resolve a single issue. It is the key to identifying cross-repository dependencies and analyzing where implementation work is truly happening.
Analyzing Cross-Repository Dependencies: This field's primary purpose is to identify issues whose solutions span multiple codebases.
Filter for Multi-Repo Work: You can easily find complex, cross-cutting issues by creating a report where
Resolving PR Project Names length > 1.Track Downstream Impact: You can find all issues from a planning repository that required changes in a specific microservice. For example, filter where
Project Name = "product-backlog" and Resolving PR Project Names contains "authentication-service".
Reporting on Implementation Location: To accurately visualize where the development effort for a project's issues is taking place, you must use the
FLATTENfunction.Effort by Repository: You can create a bar chart showing which repositories receive the most code changes. Use a custom formula dimension like
FLATTEN(resolving_pr_project_names)with aCOUNT()metric. When filtered to a single issue project (e.g.,Project Name = "mobile-app-project"), this shows you which backend services or shared libraries are most frequently modified to support mobile development.
Measuring Architectural Coupling: You can create KPIs to measure how tightly coupled your repositories are.
A custom metric like
AVG(LENGTH(resolving_pr_project_names))calculates the average number of repositories that need to be changed to resolve a single issue. A high or rising number could be an indicator of increasing architectural complexity or technical debt.