July 7, 2026
Bitbucket pull request pages already have a lot of useful information.
The hard part is that the information is often arranged as a flat list. The list is accurate, but the work still takes manual sorting. A developer has to decide which repos matter, which authors need a response, which pull requests are stale, and which changes can wait.
That is the product space behind Review Triage for Bitbucket: make the queue easier to act on without turning it into a broad management system.
The queue is a separate problem
Code review is already demanding. It takes context and enough focus to understand someone else's change.
The queue should not add much friction before the review begins. A better Bitbucket review workflow should help a developer answer a few direct questions:
- Which pull requests are relevant to me?
- Which ones are stale?
- Which ones touch watched repositories?
- Which ones come from a team or project I care about?
- Which ones can be muted for now?
- Which titles or branches contain important keywords?
That is review triage. It happens before the code review itself, and it shapes where attention goes.
Keep the first version narrow
It would be easy to make the product too broad. The nearby ideas are obvious: analytics, reports, team dashboards, reviewer scoring, project tracking, and AI review summaries.
Some products need those surfaces. This one does not need to start there. The useful first version is smaller:
- Sort the queue.
- Highlight what matters.
- Mute what does not matter today.
- Save rules people can understand.
- Stay close to the Bitbucket page.
A narrow product is easier to explain, easier to trust, and easier to stop using if it does not help.
Privacy affects product shape
Review workflow tools sit near sensitive work. Even metadata can say a lot about a team: repo names, project names, branch names, review timing, and internal priorities.
For this product, the useful boundary is queue metadata and page context. Source code and diffs should not be pulled into the product unless a feature truly requires it.
That boundary matters for a future Atlassian Forge app. Teams need to understand what an app reads, stores, and sends before they install it.
What useful triage looks like
The first useful feature set is practical:
- Watched repositories
- Team or project priority rules
- Keyword highlighting
- Stale pull request surfacing
- Muted authors, repos, or projects
- Clear visual grouping
- Settings that make sense without a training call
The product test is simple: can a developer open the Bitbucket pull request queue and see what deserves attention faster than before?