Order in the Queue¶
Source: hooks/ways/softwaredev/delivery/groundwork/sequence/sequence.md
Frontmatter
| Field | Value |
|---|---|
description |
ordering a queue of open pull requests and issues so changes that establish verification land before changes that assume it, and holding changes into an area nobody can yet test or deploy |
vocabulary |
queue ordering triage order backlog land first jump the queue hold blocked on prerequisite stack piling up unverifiable module merit versus order which first sequence open prs |
refire |
0.2 |
scope |
agent, subagent |
A change can be individually good and still wrong to accept now. Premature names that: a question of order. Five reasonable capabilities merged onto a module nobody can test make the module harder to fix and each other harder to trust.
Triage by readiness¶
For each open item, name the area it touches and check that area against the four conditions in delivery/groundwork. Then place the item:
| The item | Placement |
|---|---|
| Establishes a missing condition: adds the test command, wires CI, makes the deploy repeatable, demonstrates rollback | Jumps the queue. |
| Assumes a condition the area does not meet: changes behaviour nobody can verify, deploys through a path nobody can repeat | Held, with the prerequisite named. |
| Touches an area that meets all four | Normal review depth per delivery/merge. |
A hold is a state with an owner and an exit condition: the prerequisite item landing, or a named person deciding the area does not need it. Record it that way (see delivery/issues, residuals). A hold without a condition is a quiet drop.
The hold sits upstream of the four-square in delivery/merge. Merge's coverage axis picks a review depth once Verify holds for the area; until then there is nothing for a reviewer to lean on.
What we do not do¶
- Merge a stack of behaviour changes into an unverifiable area because each one is small.
- Write the tests after the queue clears.
- Rank items by how well they are argued instead of by what they make possible.
Common Rationalizations¶
| Rationalization | Counter |
|---|---|
| "This PR is fine on its own" | On its own it is. In this area, nothing is. Land the verification first. |
| "Holding it will annoy the contributor" | Holding with a named prerequisite is respect. A silent merge into an untestable module is the disrespect. |
| "We'll add coverage once these are in" | Then we'll be covering five changes at once and guessing which one broke it. |
| "The area has never had tests and it's been fine" | Then the first item that adds one is the most valuable thing in the queue. |
See Also¶
- delivery/merge(softwaredev) — review depth once the area is ready
- delivery/issues(softwaredev) — recording a hold as a residual with an owner and a reopen condition
- delivery/groundwork(softwaredev) — parent: the four conditions