Review

A build can change a lot at once. Review ranks what changed and puts the parts most worth a human look at the top, so "has anybody checked this" is a question with an answer.

The review queue: a ranked list of candidates on the left, the code for the selected one on the right, and Keep and Reject buttons with a note field beneath it.

Three sections

Queue is the main one — everything from the latest build waiting on a verdict, most notable first.

Frontend is the same idea for the parts people see rather than the parts they do not.

Fixes is what you have rejected. Rejecting something on the queue turns it into a fix here, ready for somebody to pick up.

A counter tells you how far through you are.

Casting a verdict

Two buttons.

Keep means this is fine. It leaves the queue and stays gone until you clear the verdict.

Reject means this needs work. It moves to Fixes, and anything you wrote in the note goes with it — which matters, because the person who picks it up is often not you, and "this is wrong" without a reason costs them the same investigation you just did.

You can also skip, which is not a verdict. It moves on without deciding.

Why something ranks where it does

Each item shows its reasons. Nothing here is a judgement about quality — it is a set of signals about what changed and how unusual it is, so a long list becomes an ordered one.

When several near-identical things changed together they are grouped, so you judge the pattern once rather than twenty times.

You can comment on specific lines: click a line number, or select some code, and say what is wrong with it.

If the screen says there is no deployed build to review, deploy the branch first. Review reads a build — with nothing deployed there is nothing to rank.

If you cannot cast verdicts

Casting and clearing verdicts needs review permission on the project. Without it you can read the queue but not judge it, and the screen tells you so rather than failing silently.

Where to go next

• Changes — the other queue, for work you asked for rather than work that was produced.
• Deployments — the build being reviewed.
• Security — problems in outside code, which review does not cover.