Forgotten locks block everyone else
Aliases: orphaned lock · forgotten unlock · lock leakage
What it is
The most common lock problem is not hostile occupation but forgetting: the holder finished editing, went to a meeting, closed the laptop, headed to lunch — and the lock is still there. Everyone who subsequently wants to touch the region is told it is "in use" by someone who has no idea. This stale lock is the signature failure of locking mechanisms: exclusivity slips from "is being edited" to "was once edited," and the system's protective logic becomes the source of the blockage. The diagnostic feature: the lock's existence has lost any connection to the holder's actual activity.
Why it happens
A lock's lifecycle depends on the holder taking an explicit closing action (mark done, close, exit) — and attention is at its most scattered exactly when editing ends. The work is finished, the mind has moved to the next thing, and the wrap-up step is the easiest to skip. Meanwhile the lock's continuation is fully decoupled from the holder's later state: going offline, switching windows, shutting the laptop — the lock notices none of it. The two effects compound, so lock lifetimes run systematically longer than real occupation. The blocking cost falls entirely on the waiters, usually with a misattribution attached — they assume the other person is still editing, feel awkward about pressing, and keep refreshing while no work whatsoever is happening. When several regions hang on different forgotten locks, the usable surface of the shared workspace shrinks at a visible pace.
Where it stops holding
Not every long-held lock is stale: someone genuinely polishing one region for a long stretch is legitimate. The discriminator is the holder's activity signal (recent edits in that region), not raw duration. Severity also depends on organizational context — in a small familiar team one message resolves it; in a large or multi-timezone organization just locating the holder can take a day, and time zones amplify the cost of every hanging lock.
Applying it
- Replace "explicit release" with "automatic by default": after a period of holder inactivity, prompt the holder to confirm release; with no response, release automatically and notify.
- Always show the holder's identity and last-activity time on the lock indicator, so waiters can tell "still polishing" from "gone."
- Give waiters a non-awkward nudge channel (one-click reminder) and an escalation fallback (request forced release), both leaving an audit trail.
- Verification: compare average lock lifetime with the interval since the holder's last activity — the gap (hang time) as a share of lifetime is the scale of the stale-lock problem; drive that share toward zero.