The purpose of the priority inbox is to gather items that you - as a developer - must action today or in the coming days.

The priority inbox leverages data from all apps you connected in order to evaluate the priority of items and the action to take for each item.

Example of prioritized items

> Pull requests first

Unlike traditional project management tools which focus mainly on issues and consider pull requests as a complementary piece of information, the priority inbox considers pull requests as a first-class citizen and takes the view that the activity of developers should be pull-request driven to keep a good merge-pace within a developer team.

For this very reason, we will always try to eliminate issues and nest them under pull requests when we detect relationships (e.g. via GitHub closing keywords or GitLab closing keywords)

A pull request resolving two issues

Click on Resolves: X items to see the resolved issues

This nesting mechanism provides a more focused inbox where issues assigned to you get progressively replaced by pull requests as you address them.

Once an issue has been transformed into a pull request inside your inbox, the pull request workflow can begin!

> The pull request workflow

At Keypup we believe in git forking models, approval flows and continuous integration. 

Therefore the priority inbox - and review & merge board - is configured to believe in the following rules:

  • An issue aims at being implemented via a pull request

  • A pull request must be peer-reviewed and approved

  • The pull request build must be green

  • If the above conditions are fulfilled then the pull request should be merged ASAP to avoid becoming stale.

Hey GitLab users! You use GitLab free edition and can't have an approval flow? We've got you covered. Read our article on how Keypup allows you to have an approval flow with GitLab free edition.

So here is what you are going to see in your inbox during for each stage of your pull request.

=> Your pull request is in development

The item appears in your priority inbox and the recommended action is Finish and assign reviewer.

=> You assign jdoe as reviewer and the build is green

You have finished your pull request and have assigned a reviewer on it. At this point in time there is nothing more you can do. 

Because you can't do much the pull request is automatically moved from the Prioritized tab to the Pending peer tab.

On the other side, the item appears in mister jdoe's priority inbox with a recommended action set to Review.

=> You assign jdoe as reviewer but your build is red

The item remains in your priority inbox and the recommended action is set to Fix build.

Note: build status is ignored if you do not have any build configured on your project.

=> Your pull request is approved by jdoe and the build is green

Well done! Your pull request is ready to be merged.

If we detect that you are a merge person for the project (= someone regularly merging PRs for this repository), the pull request will be moved to your inbox with a recommended action set to Merge.

=> Someone merged another pull request and my changes are conflicting

Life is unfair sometimes. Your pull request comes back to your priority inbox and the recommended action is set to Rebase.

> The prioritization process

Items displayed in your priority inbox are automatically ordered based on the priority evaluated by our engine.

There are four priority levels at this stage:

We use various elements on your issues and pull requests to evaluate priorities such as the review status, build status, mergeability check etc. but as a rule of thumb you can remember that:

  • Overdue items are likely to appear as Critical

  • Items due within 3 days are likely to appear as Important

  • Items due within 7 days are likely to appear as Medium

  • Items with no due date are likely to appear as Low

Due dates are automatically inferred based on related items (e.g. the ones related via GitHub closing keywords or GitLab closing keywords). The soonest due date will always be considered when a pull request is related to issues.

This is a simplified version of course but it gives a good indication as to what to expect. We are working hard on making our engine smarter and smarter and have the vision that prioritization should naturally occur by learning from your data.

Think our prioritization rules don't provide the results you expect? Don't worry. You have the ability to customize prioritization rules to better match your dev workflow.

> Actions available from the priority inbox

The priority inbox currently provides three actions.

You forgot to add a closing keyword in your pull request description? Just click the link icon at the top right of each item to relate other items.

=> Merge green pull requests

Pull requests which are approved with a green build will be considered mergeable. You can click on the tick icon at the top right of the card to merge the pull request.

A Quick reply field is available on each priority inbox item. Using this action you can quickly leave a status update on issues or pull requests without leaving Keypup.

This Quick reply field is also available for related items when a pull request is grouped with related issues.

Commenting on the All activity or PR only feeds leaves a message on the pull request.

Commenting on a related issue leaves a message on that specific issue.

This is particularly useful to provide status updates to project managers following development activities from a project management tool such as JIRA, Trello or Clickup - all integrated to Keypup - and with no access to GitHub/GitLab.

Did this answer your question?