A sitting

This is the one idea that everything else in Deliver, Changes and a good deal of the rest of the product assumes you already understand. It’s unusual, it’s load-bearing, and it has a slightly old-fashioned name on purpose: think of it the way a committee “sits” to consider something, once, for one reason, and then the sitting is over.

What it is

A sitting is one editing visit: everything you change in one sitting shares one reason (the justification you type), becomes one row in the change register, and, if it’s ever undone, is undone as one unit, never field-by-field.

Concretely: you open a work package, change its name and its programme year, and type one sentence explaining why. That’s one sitting, with two field changes in it. You didn’t write two justifications for two edits, you wrote one, for the visit.

This matters because the previous version of this product let almost every kind of edit skip past change control by going through one giant “save everything” button that asked for no reason at all. The redesign’s rule is deliberately strict: there is no way to change the plan that doesn’t go through a sitting. Whatever screen you’re on, whatever you’re editing, it becomes a sitting with a justification, recorded in the register.

What you’ll actually see

On Deliver → Changes → Mine, editing a work package’s own fields shows this directly: you change a value, a Save bar appears at the bottom showing which fields you’ve touched, and you’re asked for one reason (“One reason for everything changed in this sitting”) before you can save. The save button reads “Save and explain” , not just “Save”, because the explanation is not optional decoration, it’s part of what you’re doing.

Creating a new deliverable is the same mechanism working differently: the deliverable and every step you named in the form save together as one sitting, but here the justification is filled in for you (something like Added "Network hardening" to WP-14 · 3 steps) rather than asked for, because adding new, additive work under a plan doesn’t need the same justification a change to something that already existed does.

What happens to a sitting after you save it

Every sitting is recorded in the change register (Deliver → Changes → All changes): what changed, who changed it, when, why, and what happened to it. Depending on how your instance is configured (see hold until approved), your sitting either:

• took effect immediately, and is now waiting to be reviewed after the fact (apply_then_review, the default), or
• is waiting for approval before it takes effect at all (hold_until_approved) , the plan looks exactly as it did before you saved, until someone with the right authority approves it.

Either way, someone with the right authority can respond to your sitting in one of three ways:

• Approve it. If it was held, it now applies to the plan. If it already applied, this just records that it’s been reviewed and accepted.
• Send it back, with a reason. If it was held, nothing ever touched the plan, so there’s nothing to undo, it’s simply discarded, and you (the author) see why. If it already applied, sending it back triggers a revert: a second, compensating sitting that puts every field back to what it was, recorded in the register as its own entry, linked to the one it undoes.
• Later, from the register specifically (not the review queue), an already-approved, already-applied sitting can be reverted on its own, the same compensating-change mechanism, used when someone decides after the fact that a change should never have gone in.

A revert (whether triggered by sending something back, or done later from the register) can refuse to happen. If something has changed underneath it since, the item was deleted, a child was added to something this sitting created, or a later sitting touched the same field again, the product will not attempt a partial undo. It tells you exactly what’s blocking it, and nothing is reverted until that’s sorted out.

What you cannot do

• You cannot approve or reject your own sitting. The product enforces this on the server, not just by hiding the button, even if you could see someone else’s UI, the request would be refused.
• You cannot “add to” someone else’s sitting that’s already open. If you try to edit something that already has a pending proposal on it, you’re asked to choose: propose a second, competing change against the current plan instead (both will show as pending, nothing here automatically picks a winner yet, so a reviewer has to apply only one), or just look at what’s proposed without touching anything.
• A sitting that touches more than one workstream needs a reviewer who can reach all of them. A reviewer who can only see part of what a sitting touches is refused the decision entirely, never allowed to approve “their part” of it.

If nothing seems to save at all

A sitting is always recorded against a baseline, see hold until approved. A normally set-up instance already has one from the moment it’s provisioned, so this shouldn’t affect you day to day , but an instance with no active baseline at all (unusual, and worth raising with whoever administers it) cannot save a change to the plan, at all, for anyone. See the administrator guide if you’re an administrator chasing this down; if you’re not, this is worth reporting rather than something wrong with what you typed.

Why it’s built this way

A sitting exists so that “what changed, and why” is always answerable from the register, without having to reconstruct it from a pile of individually-approved field edits that may or may not have shared a reason. It’s also what makes revert possible at all: because a sitting’s effect on the plan is recorded as one coherent unit (a set of before/after values, tied to one register entry), undoing it is “put these fields back,” not an unpickable tangle of separately-approved changes.

Where to go next

• Derived versus declared: what a sitting can and can’t actually change (you cannot type a value into a field the product works out for you).
• Hold until approved: the two ways your instance can be configured to handle the gap between saving a sitting and it taking effect.
• Reach: why you might not be offered the choice to review a particular sitting at all.
• The Changes section of this guide, for the review queue, the register, and “Mine” in full.