Dataset: Issues & Pull Requests
Entity: Pull Requests, Issues
Field ID: recommended_action
Type: Select list
For Pull Requests:
The action that Keypup recommends (e.g. review, merge, etc.) is based on the status of the pull request (approval status, build status, etc.).
ASSIGN_REVIEWER: The PR has not been updated in 3 days and has no reviewers assigned. The author may have finished their work and forgot to assign reviewers.ASSIGN_MISSING_REVIEWERS: The PR has fewer reviewers assigned than the number of required approvalsFIX_BUILD: The PR has its build failingFIX_CODE: The PR has one reviewer who requested changes to the codeMERGE: The PR is approved and has a green build. It is time to merge it.NONE: The PR is merged or closed. Also used as a fallback value when we couldn’t detect a useful recommendation.REBASE: The PR is conflicting with the base branch and must be updated (rebased)REVIEW: The PR is currently waiting for reviewers to perform their reviews until one request changes or the number of approving reviews exceeds the number of required approvals.
For Issues:
The action that Keypup recommends is based on the status of the issue (implementation status, related pull requests, etc.). Read more here.
CLOSE: The issue must be closed as ALL resolving pull requests have been merged or closed.IMPLEMENT: The Issue is open and has no resolving pull requests yet.WAIT_FOR_IMPLEMENTATION: The issue is resolved by one or several pull requests that are currently open (not merged or closed)
Source: Calculated
Transformation logic (Pull Requests): Evaluated based on the current review status, build status, and implementation status of the pull request or issue. See the description above for details about each recommendation. The order of precedence for PR recommendations is the following:
NONE(if the item is merged or closed)REBASEFIX_BUILDASSIGN_MISSING_REVIEWERSREVIEWFIX_CODEMERGEASSIGN_REVIEWERNONE(fallback)
Transformation logic (Issues): Evaluated based on the current implementation status of the issue and its related pull requests. See the description for details about each recommendation. The order of precedence for issue recommendations is the following:
NONE(if the item is closed)WAIT_FOR_IMPLEMENTATIONCLOSEIMPLEMENTNONE(fallback)
From: |
|
Github (PRs, Issues) | Calculated |
Gitlab (PRs, Issues) | Calculated |
Bitbucket (PRs) | Calculated |
Azure DevOps (PRs, Issues) | Calculated |
JIRA (Issues) | Calculated |
ClickUp (Issues) | Calculated |
Trello (Issues) | Calculated |
Extended logic
Recommended Actions On Pull Requests
The recommended action field is based on an industry-standard stipulating that pull requests should broadly follow the lifecycle below:
A pull request gets opened and is actively worked on.
If left untouched for a few days and with no reviewers, the author likely forgot to assign reviewers. Reviewers must therefore be assigned or active work must be resumed.
Before review, the pull request must be up to date with the base branch (no conflicts) and must have a green build - so reviewers review the final version of the pull request.
To be approved, a pull request must receive a minimum number of approvals. This minimum number of required approval(s) is set in each repository system (GitHub, GitLab, Bitbucket). Keypup always considers that each pull request should receive at least one approving review.
A reviewer rejection means the author of the pull request must perform additional work and request a re-review. This restarts the cycle to step (1).
Once a pull request is green on all three aspects (review, build, and base branch), it can be merged.
Recommended Actions On Issues
The recommended action on issues is much simpler as teams have many different completion workflows. Keypup takes the assumption that issues will broadly follow this lifecycle:
An issue must be implemented by a pull request. The relationship between the issue and its pull request is discovered via auto-closing keywords.
When an issue is related to an open pull request, it is considered as being implemented.
When all pull requests related to an issue have been closed or merged, Keypup considers that the issue should get closed at some point - probably after following some QA and release processes on your side.
Reporting Use Cases
The Recommended Action field is a dynamic, computed attribute that acts as a real-time guide for your workflow, categorizing each open item by its most logical next step. It is exceptionally powerful for creating actionable dashboards and identifying process bottlenecks.
Building Actionable Dashboards and Boards: The primary use of this field is for filtering columns in a Kanban-style board (like the "Activity Pipe" widget) to automatically sort work by its current stage.
Review Queue: Create a column for senior developers showing all pull requests ready for review with a filter like
Recommended Action = "REVIEW".Merge Queue: Create a "Ready to Deploy" column by filtering where
Recommended Action = "MERGE".Blocked Work: Build a column to highlight all pull requests that are blocked and need developer attention by using a filter like
Recommended Action equals any of "FIX_BUILD,FIX_CODE,REBASE".
Identifying Workflow Bottlenecks: When used as a dimension, this field provides a high-level overview of where work is piling up in your development process.
A bar chart with
Recommended Actionas the dimension andCOUNT()as the metric will instantly show you how many items are stuck at each stage. A large number of items in the "REVIEW" category, for example, is a clear sign of a review bottleneck. Similarly, a high count in "FIX_BUILD" could point to instability in your CI pipeline.
Prioritizing Work with Combined Filters: You can combine this field with others to create highly specific, prioritized lists.
For example, you can find the most urgent reviews by creating a report of items where
Recommended Action = "REVIEW" and due_on before today, highlighting overdue items that are blocked on a pending review.