A Decision Log Is How a Nebulous Role Becomes Inheritable

# A Decision Log Is How a Nebulous Role Becomes Inheritable ## Claim A role defined by judgment rather than by steps can only be handed on by publishing the decisions and their reasons, because the reasoning is the entire job and nothing else records it.  ## Evidence **Source**: [[3. Resources/Readwise/Articles/WordPress 7.1 Release Lead Decision Log|WordPress 7.1 Release Lead Decision Log]] — Anne McCarthy, stating why they wrote it > [!quote] > I promise that one day I will write about something other than WordPress 7.1 but, for now, I want to leave a trail of breadcrumbs for future WordPress folks. Releases are a whirlwind and I often find myself scratching my head trying to remember, “Why did we do X and not Y?”. Tied to this, the release lead role is fairly nebulous and I wanted to publicly document some of the various decisions that had to be made. Two things are named and they are causally linked. The role is **nebulous** — no checklist defines it — and the author, who has done adjacent release work before, cannot reconstruct her own prior reasoning. If the person who made the decisions cannot recover them, no successor can infer them. What the log actually preserves is not the outcomes. Anyone can read the changelog and see that real-time collaboration was punted, that the Table of Contents block did not ship, that responsive styling got a disable switch. What is unrecoverable from the artifacts is *why*: that RTC was punted early and deliberately, "as early as possible to ensure we could focus on more realistic items"; that the disable switch was chosen because "a full removal was disproportionate"; that the toolbar change was reverted rather than debated because the debate "had run for several days without agreement." The form matters too. It is dated, ordered oldest to newest, one decision per entry with reasons below — and explicitly incomplete, with a stated intention to update. That makes it a record someone can extend rather than a retrospective that closes. ## Scope & conditions - **Holds** for judgment-shaped roles — release lead, maintainer, incident commander, editor — where the same inputs could licence several defensible calls and the choice among them is the contribution. - **Requires publication, not just recording.** A private log preserves the individual's memory; a public one transfers it. McCarthy's is on her own site, linking to the Slack threads, Trac comments, and PRs where each call was actually made. - **Partial is fine and worth saying.** The log declares itself incomplete and expects revision. A standard of completeness would have prevented it from existing. - **Breaks** where decisions are genuinely procedural. A checklist role does not need a decision log; it needs the checklist. - **Does not follow** that the reasoning is portable as rules. A successor inherits worked examples and the shape of the judgment, not a decision procedure. ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — the practical answer to how a volunteer project retains what a departing role-holder knew - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — the deliberate counter-move to coordination state that lives nowhere - [[3. Resources/Permanent Notes/Coordination Work Bottoms Out on State That Was Never Written Down]] — because contrasts, and completes it: that note says the limiting input is state nobody recorded. This is the practice that records the recoverable part of it, and its own admission of incompleteness marks where the limit actually sits. - [[3. Resources/Permanent Notes/Contribution Pathways Must Be Documented Not Left Emergent]] — because extends: that note argues the route from intent to action must be an owned artifact; this applies the same rule to the role at the far end of that route. - [[3. Resources/Permanent Notes/A Capability Transfer Is Proven by Absence Not by a Handoff]] — applies-in: the log is an input to transfer, and by that note's test it is not yet evidence — the next release lead's run is. - [[3. Resources/Permanent Notes/Maintenance Is Most of the Work but Gets No Prestige]] — because evidence-for: writing the log two days after release day is unglamorous, unfunded, and the reason the next lead starts from something. - [[3. Resources/Permanent Notes/Corporate Contribution Fails on Legibility Not Goodwill]] — because extends: legibility is the same currency here, spent on making a role's judgment visible rather than a sponsor's investment. ## Tests / falsifiers - Ask the next WordPress release lead which entries they actually used. If the log goes unread, its value was in the writing rather than the inheriting, which is a weaker claim than this one. - Compare a project that keeps decision logs against one that does not, on how long a new role-holder takes to make calls without escalating. That gap is what the log is buying. ## Maintenance - Last tended: 2026-08-28 - Next review: 2026-11-28 ## Source [[3. Resources/Readwise/Articles/WordPress 7.1 Release Lead Decision Log|WordPress 7.1 Release Lead Decision Log]]