The purpose of the priority inbox on Keypup is to gather items that you - as a developer - must action rapidly.
The priority inbox leverages data from all apps you connected in order to evaluate the priority of items and the actions to take for each of them.
Pull requests first
Unlike traditional project management tools which focus mainly on issues and consider pull requests as a complementary piece of information (because they are not designed for developers!), the Keypup priority inbox considers pull requests as first-class citizens and takes the view that the activity of developers should be pull-request driven to keep a good merge-pace within a developer team. We are developers too remember? So we know what world you live in!
#proverb "Pull request or it didn't happen"
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 according to 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 before merge
- If the above conditions are fulfilled then the pull request should be merged ASAP to avoid becoming stale.
#protip 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
Bad bad! :)
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. The item is moved back to your priority inbox with a recommended action set to Merge.
It will also appear in green with the action button Merge in your Keypup Review and Merge board, where you can see all your PR status at a glance and action directly.
#comingsoon we are in the process of implementing a feature to automatically detect active project maintainers. When this feature comes out the pull request will be moved to the maintainers' priority inbox instead of coming back to your priority inbox (unless you're a maintainer of course).
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 shortest deadline will always be considered when a pull request is related to issues.
This is a simplified view of our magic engine, 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 two actions.
Link pull requests to issues
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 link other items.
Comment on pull requests or issues
A Quick reply field is also available for on items and related items (related items appear when a pull request is grouped with related issues).
Commenting on the All activity feed 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 or Clickup- both integrated to Keypup - and with no access to GitHub/GitLab.