Skip to main content

Issues and PRs > Resolving PR Projects

Arnaud Lachaume avatar
Written by Arnaud Lachaume
Updated yesterday

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 project field 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 FLATTEN function.

    • 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 a COUNT() 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.

Did this answer your question?