Removing Inactive Maintainers  🔗 **Source:** [Removing Inactive Maintainers](https://duckalignment.academy/inactive-maintainers/) > [!note]+ Document Notes > tags: [open-source-governance, maintainer-lifecycle, supply-chain-security, community-management, account-compromise, policy-design, fedora] > author: Duck Alignment Academy — byline not in capture; strong indications of Ben Cotton (see Attribution) > source: https://duckalignment.academy/inactive-maintainers/ > reference: "Removing inactive maintainers" — Duck Alignment Academy > date created: 2026-08-26 21:10 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Removing inactive maintainers > > **Attribution — inferred, with the basis stated.** Reader's `author` field reads `duckalignment.academy`, a domain. **No byline in the capture.** Three things point strongly to **Ben Cotton**, who runs Duck Alignment Academy and was **Fedora Program Manager**: the Fedora specifics are insider-level (that activity evaluation *"requires checking half a dozen services"*, and that **Mattia Verga** wrote the packager-inactivity script); the framing hangs on **calendar-based release cycles**, which is Fedora's model and a program manager's instinct; and the register matches his published work on open-source program management. **This is a reviewer inference, not a stated byline — verify on the live page before citing by name.** > > **Register.** A short, practical **governance how-to** — 798 words, no citations, no data, and no interest in being anything grander. **It is advice, and it knows it.** The distinguishing quality is that it takes the *social* obstacle as seriously as the technical one. > > **Why it matters here.** Two reasons. It reframes maintainer hygiene from a **merit question into a security question**, which changes the correct threshold. And it is the **eighth enforcement-boundaries instance in this batch** — and the clearest statement yet that a *scheduled* check binds where a good intention does not. > <!-- deep-read:sections start --> ## 🧭 Table of Contents 1. Summary 2. Main Content and Notes 3. References 4. Paraphrase 5. Newsletter 6. Action Items 7. Hypotheses 8. Methodology 9. Questions 10. Future Research 11. Implications 12. Learning Styles Assessment 13. Accessibility Assessment 14. DEIB Assessment 15. Logical Validity 16. DARVO Analysis 17. Conclusion 18. Refactor Appendix 19. Template Library ## 🔗 References (in-page) - **Fedora** — the worked example, cited for scale and complexity: *"a large and complicated project, so evaluating activity requires checking half a dozen services."* - **Mattia Verga** — named, credited with the script that *"handles the checks and creates issues in a repo to track the inactive packagers."* **The only named individual and the only concrete implementation.** - **No other citations.** No studies, no incident data, no supply-chain research — despite the security claim being the argument's strongest leg. ## 📝 Summary **The asymmetry it opens on:** > *"In open source projects, we tend to grant privileges far more often than we remove them. This is understandable, but risky."* **Two harms, and the ordering matters.** First, frustration — *"someone may go to them with a question and be frustrated when they don't get an answer."* Then the one it flags as **more important**: > *"it presents a security risk. Compromised accounts remain a common attack vector, and it's much easier to escape notice if the account owner isn't using the account."* **Three reasons nobody does it**, each named honestly: it's **boring**, it's **complicated** (*"What does it mean to be 'inactive'?"*), and it **hurts feelings** — *"People who earn privileges absorb that role into their identity and they don't want to let it go."* > *"This is a case where the perfect quickly becomes the enemy of the good (or okay-ish)."* **On boring**, the concession is refreshing: *"Project and community management tasks often end up on the 'avoid: no fun' pile. They only seem like no fun because they are."* Followed by the analogy: *"Changing the air filter in my furnace isn't fun, but it's important for the health and safety of my family."* And the permission to do it badly: *"if you go through the list and identify inactive maintainers once or twice a year, that's better than nothing."* **On complicated:** *"You can define it in the way that's most convenient to you. The goal isn't to be rigorous and precise, it's just some spring cleaning."* Start with *"have I seen So-and-so around lately?"* And: **"Again, it would be nice if you could automate it. You don't need to wait for that."** **On feelings**, the one place he refuses the shortcut: *"Unlike the other two, you can't really half-ass this one, so you need a policy that treats people with kindness."* **The policy — eight features.** 1. **Define "inactive" unambiguously.** *"We will remove maintainers who have not been active in N months, where 'active' means having done X, Y, Z."* Six or twelve months as a start; enumerate broadly — *"commits, issues opened/closed/commented/reviewed, pull requests, mailing list posts."* 2. **Define "inactive" generously — and this is the piece's key move:** > *"the bigger concern is 'is this person still in control of their account?' not 'is this person earning enough points to keep their privileges?' So if someone's activity isn't what you'd want for them to initially earn maintainer status, that's probably okay."* 3. **Check at a set time.** Tie it to the release cycle — *"Right after the release is a good starting point."* 4. **Automate what you can.** *"The time spent really does pay off pretty quickly."* The Fedora example, with Mattia Verga credited by name. 5. **Don't remove anyone without notice.** *"Some will respond by being more active. Some will respond by saying 'yeah, I no longer have the time and/or interest, so go ahead and drop me.' Some won't respond at all."* And: **"If someone wants to remain, let them."** 6. **Conspicuously acknowledge the people you're removing.** *"maintainer emeritus"*, plus *"a blog post, release notes, or other vehicle for public praise."* 7. **Allow easy reinstatement**, with the reason that makes it work: > *"It's much easier to let a role go if you know you can easily get it back later."* 8. **Leave some privileges on emeritus status** — historical listing, project email, voting rights on certain issues — *"will help people who are inactive still feel valued in the project."* **The closing permission:** *"It will take a few tries to get the policy just right. Don't be afraid to try it."* ## 📖 Main Content ### 🗒️ Notes **The problem.** - *"In open source projects, we tend to grant privileges far more often than we remove them. This is understandable, but risky."* - **Harm 1 — user-facing:** *"keeping inactive people on the maintainer list means someone may go to them with a question and be frustrated when they don't get an answer."* - **Harm 2 — and explicitly ranked higher:** *"More importantly, it presents a security risk. Compromised accounts remain a common attack vector, and it's much easier to escape notice if the account owner isn't using the account."* - **The mechanism, stated compactly:** an unused account is a compromised account nobody will notice. **Dormancy is what makes it attractive.** - *"It behooves the project to keep the maintainer (or other privileged role) list tidy."* **Three obstacles.** 1. *"it's boring, tedious work. Who wants to do that?"* 2. *"it's complicated work. What does it mean to be 'inactive'?"* 3. *"it can lead to hurt feelings. People who earn privileges absorb that role into their identity and they don't want to let it go."* - **The framing that governs the whole piece:** *"This is a case where the perfect quickly becomes the enemy of the good (or okay-ish)."* **Obstacle 1 — boring.** - *"Project and community management tasks often end up on the 'avoid: no fun' pile. They only seem like no fun because they are."* **Concedes the point rather than arguing it.** - *"But 'fun' and 'important for the project' aren't the same."* - **The analogy:** *"Changing the air filter in my furnace isn't fun, but it's important for the health and safety of my family."* - **The permission to under-deliver:** *"Ideally, the inactive maintainer process is automated and runs regularly, but building that automation takes work. So if you go through the list and identify inactive maintainers once or twice a year, that's better than nothing."* **Obstacle 2 — complicated.** - *"'Inactive' can mean a lot of things. Does one activity in a six month period count? Does the activity have to be 'sustained'?"* - *"You can define it in the way that's most convenient to you. The goal isn't to be rigorous and precise, it's just some spring cleaning."* - **The minimum viable version:** *"You can start by just asking yourself 'have I seen So-and-so around lately?' If the answer is 'yes', then they're active."* - **The anti-paralysis line:** *"Again, it would be nice if you could automate it. You don't need to wait for that."* **Obstacle 3 — feelings.** - *"The feelings objection is the hardest one. We're all friends here and we don't want to hurt our friends' feelings."* - **The one exception to good-enough:** *"Unlike the other two, you can't really half-ass this one, so you need a policy that treats people with kindness."* **The eight policy features.** 1. **Unambiguous definition.** *"We will remove maintainers who have not been active in N months, where 'active' means having done X, Y, Z."* Six or twelve months suggested. *"Be sure to include as many activities as you can reasonably determine. Think about what's important to keep that status: commits, issues opened/closed/commented/reviewed, pull requests, mailing list posts, and so on."* 2. **Generous definition — the reframe.** *"For the most part, the bigger concern is 'is this person still in control of their account?' not 'is this person earning enough points to keep their privileges?' So if someone's activity isn't what you'd want for them to initially earn maintainer status, that's probably okay."* - **Reviewer note: this is the analytical core.** The security question and the merit question have different correct thresholds, and conflating them produces a policy that is simultaneously harsher than necessary and worse at the thing it's for. 3. **Set time.** *"If you have calendar-based releases, check at a given point in the release cycle. Right after the release is a good starting point."* 4. **Automate what you can.** *"The time spent really does pay off pretty quickly."* - **Fedora:** *"a large and complicated project, so evaluating activity requires checking half a dozen services."* - **Mattia Verga wrote a script** that *"handles the checks and creates issues in a repo to track the inactive packagers."* 5. **Notice before removal.** *"This is a big part of the 'don't hurt your friends' feelings' requirement. Give people a chance to respond."* - Three outcomes anticipated: renewed activity · explicit release (*"yeah, I no longer have the time and/or interest, so go ahead and drop me"*) · no response. - **"If someone wants to remain, let them."** — **the policy has no override.** 6. **Conspicuous acknowledgment.** *"Add people as a 'maintainer emeritus'. Mention them in a blog post, release notes, or other vehicle for public praise."* 7. **Easy reinstatement.** *"If someone lapses and later wants to return, let them. Don't make them go through the whole process again."* - **The mechanism:** *"It's much easier to let a role go if you know you can easily get it back later."* 8. **Retained privileges on emeritus.** *"Keeping their name on a list of historical maintainers, letting them keep a project email address, giving them voting privileges on certain issues, and other privileges will help people who are inactive still feel valued in the project."* **Closing.** *"It will take a few tries to get the policy just right. Don't be afraid to try it."* ## 📚 References - **Mattia Verga's Fedora script** — **the most actionable item here**, named and unlinked. Checks activity across services and files issues to track inactive packagers. **Worth finding for anyone building the same thing.** - **Fedora's own inactive-packager policy** — implied by the script's existence, not cited. **A real, running, at-scale implementation of everything this article recommends.** - **What is conspicuously absent:** any citation for *"Compromised accounts remain a common attack vector."* **This is the argument's strongest leg and it carries no evidence** — no incident, no study, no supply-chain report, despite an abundance of well-documented cases involving dormant or transferred maintainer accounts. - **Cross-batch pairings:** - **WP Rocket's post-mortem** — *"reviewed but never assigned to an owner, so it fell out of view."* **The same underlying failure from the opposite direction.** - **Cunningham** — maintainer emeritus is a retention mechanism for exactly the institutional memory she says stops transmitting. - **The Monzo staff engineer** — *"commitment has shape"*; here, **a privilege has a shape too, and dormancy is not it.** ## 🗣️ Paraphrase **On the reframe that makes the whole thing work.** The obvious way to think about removing maintainers is as a **merit** question — has this person earned continued status? That framing is why the task feels awful: it turns spring cleaning into a judgment on people you like. > *"the bigger concern is 'is this person still in control of their account?' not 'is this person earning enough points to keep their privileges?'"* **Changing the question changes the correct threshold.** If you are asking about account control, one commit in twelve months answers it completely — and you can be generous without weakening the policy at all, because **generosity costs nothing against the security question and everything against the merit question.** The reframe makes the policy simultaneously kinder and more effective, which is rare. **On the security claim, which is right and unevidenced.** *"Compromised accounts remain a common attack vector, and it's much easier to escape notice if the account owner isn't using the account."* **The mechanism is exactly correct and worth stating more sharply than he does: dormancy is not incidental to the risk, it is the attractive property.** An attacker taking over an active maintainer's account is racing that maintainer's own attention — unexpected commits get noticed, 2FA prompts get questioned. **Take over an account nobody has used in two years and there is no one to notice.** The dormant account is the *better* target, and a project's inactive list is a published inventory of them. **But the piece cites nothing.** No incident, no study, no supply-chain report — and there is no shortage of well-documented cases involving dormant or transferred maintainer credentials. **For a 798-word how-to that's forgivable; for the argument's load-bearing claim it's still a gap**, and it's the one thing that would move a reluctant project from "we should" to "we must." **On taking the social obstacle seriously, which most governance writing doesn't.** *"People who earn privileges absorb that role into their identity and they don't want to let it go."* **That is the actual reason these lists don't get trimmed**, and naming it as identity rather than ego or entitlement is both accurate and generous. **And the structural remedy is better than the emotional one.** He doesn't advise being tactful; he advises **removing the stakes**: > *"It's much easier to let a role go if you know you can easily get it back later."* **Reversibility is what makes the loss survivable.** Combined with emeritus status, public acknowledgment, and *"if someone wants to remain, let them"*, the policy is designed so that being removed **costs almost nothing** — which is precisely why people will accept it. **The kindness is architectural, not interpersonal.** **On the enforcement point, which is the batch's eighth instance.** *"Check for inactive maintainers at a set time… Right after the release is a good starting point."* **A calendar trigger is the mechanism; intent is not.** Everyone reading this already agrees the list should be tidy — that agreement has produced nothing, which is the piece's premise. **What converts agreement into action is a specific recurring moment when the check happens.** This is the same structure as *"someone now owns GitHub triage"* from the WP Rocket post-mortem, as *"commitment has shape"* from the Monzo talk, and as Meta building the constraint into the interview task rather than into a rule. **Eight independent sources this month, and the pattern is identical: a stated intention binds nothing; a scheduled or structural mechanism binds.** **On the anti-perfectionism, which is the most practically useful thing here.** *"You don't need to wait for that."* *"That's better than nothing."* *"The goal isn't to be rigorous and precise, it's just some spring cleaning."* *"have I seen So-and-so around lately?"* **Automation is presented as the destination and explicitly refused as a prerequisite.** That matters because *"we'll do it properly once we've built the tooling"* is how this task gets deferred indefinitely — and **the deferral is the vulnerability.** A crude annual review that ships beats a rigorous automated system that doesn't. **The one thing I'd add that he doesn't say.** He treats the security harm and the feelings harm as separate problems to be balanced. **They point the same direction.** A maintainer who has drifted away and still has commit rights is carrying an unbounded liability on the project's behalf, indefinitely, for a role they are no longer performing. **Removing them is also a favour to them** — and framing it that way would make the conversation easier than any amount of emeritus ceremony. ## 📰 Newsletter **The maintainer list nobody wants to clean is a published inventory of your best attack targets.** A short piece from Duck Alignment Academy makes the case better than any security advisory I've read, and it does it in 798 words: > *"Compromised accounts remain a common attack vector, and it's much easier to escape notice if the account owner isn't using the account."* **Dormancy isn't incidental to the risk — it's the attractive property.** Take over an active maintainer's account and you're racing their attention: unexpected commits get noticed, unexpected 2FA prompts get questioned. **Take over an account nobody has touched in two years and there is nobody to notice.** **But the reframe is the part worth stealing.** Everyone thinks about removing maintainers as a *merit* question — has this person earned continued status? That's exactly why it feels awful, and why it never gets done. He flips it: > *"the bigger concern is 'is this person still in control of their account?' not 'is this person earning enough points to keep their privileges?'"* **Change the question and the threshold changes.** If you're asking about account control, one commit in twelve months answers it. You can be extremely generous and lose nothing — **generosity costs nothing against the security question and everything against the merit question.** The policy gets kinder *and* more effective, which almost never happens. He's honest about why this doesn't get done: it's boring (*"They only seem like no fun because they are"*), it's fiddly, and it hurts feelings — *"People who earn privileges absorb that role into their identity and they don't want to let it go."* **And the remedy for the feelings problem is structural, not interpersonal.** He doesn't tell you to be tactful. He tells you to remove the stakes: > *"It's much easier to let a role go if you know you can easily get it back later."* Plus emeritus status, public acknowledgment, notice before removal, and — importantly — **"If someone wants to remain, let them."** No override. **The kindness is in the architecture.** **The most useful line for anyone who's been meaning to do this since 2023:** *"Again, it would be nice if you could automate it. **You don't need to wait for that.**"* Start with *"have I seen So-and-so around lately?"* Once or twice a year *"is better than nothing."* Because *"we'll do it properly once we've built the tooling"* is how the task gets deferred forever — **and the deferral is the vulnerability.** **One thing he doesn't say and should:** a maintainer who drifted away and still holds commit rights is carrying an unbounded liability on the project's behalf, indefinitely, for a role they're not performing. **Removing them is a favour to them too.** That framing makes the conversation easier than any amount of emeritus ceremony. **And one gap:** the security claim — the article's strongest leg — carries no citation. No incident, no study, no supply-chain report, and there's no shortage of documented cases involving dormant or transferred maintainer credentials. It's the one thing that would move a reluctant project from *we should* to *we must*. **If you maintain anything with a privileged-user list — a plugin repo, a GitHub org, a package namespace — the action is one calendar entry.** Right after your next release. ## ✅ Action Items **DevRel** - `#action/h1` **"Is this person still in control of their account?" is the reframe** — it turns an uncomfortable merit judgment into a routine security check, and it's the whole reason the policy becomes doable. - `#action/h2` **"You don't need to wait for that"** is the line that unblocks people. **Automation as destination, explicitly refused as prerequisite.** - `#action/h2` The furnace-filter analogy is a good way to make the case for unglamorous maintenance work generally. **OSPO** - `#action/h1` **The eight-point policy is a ready-made template** and can be adopted nearly verbatim. **Highest-value item in this source.** - `#action/h1` **Reversibility as the mechanism for reducing resistance** — *"much easier to let a role go if you know you can easily get it back"* — generalises well past maintainer lists to any status, role, or access grant. - `#action/h2` **A scheduled trigger tied to the release cycle** is what converts agreement into action. **Eighth enforcement-boundaries instance in this batch.** **Community** - `#action/h1` **Maintainer emeritus is an institutional-memory mechanism**, not just a courtesy. It keeps people reachable who would otherwise disappear entirely — **which is directly relevant to Cunningham's transmission problem.** - `#action/h2` *"People who earn privileges absorb that role into their identity"* is the honest diagnosis of why offboarding is hard, and it deserves to be said out loud in community-management conversations. **WordPress subteams** - **Meta** — `#action/h1` **The most directly applicable subteam.** wp.org commit access, plugin and theme committers, and GitHub org membership are all privileged-role lists with the same dormancy exposure. **The Fedora model — automated checks filing tracking issues — is a concrete pattern.** - **Plugins, Themes** — `#action/h1` **Directory committer lists are the highest-risk surface** in the WordPress ecosystem for exactly the reason stated: a dormant committer on a widely-installed plugin is an attractive, unwatched target. **This is a supply-chain concern, not a tidiness one.** - **Community** — `#action/h1` Emeritus status, easy reinstatement, and public acknowledgment are directly adoptable for team reps, meetup organisers, and contributor roles. - **Core, Core Program Team** — `#action/h2` **Tie the check to the release cycle** — *"right after the release is a good starting point"* — which fits WordPress's calendar-based model exactly. - **Hosting, Documentation, Training, Support, Polyglots, Openverse, Photos, TV, Mobile, Design, Accessibility, CLI, Playground, Marketing, Core AI, Core Performance, Tide** — `#action/h3` **Applicable in principle to any team with a privileged-role list**, though none is the natural owner of the policy. **The WPOCC** - `#action/h2` Relevant to any organisation maintaining volunteer roles and access — and the **easy-reinstatement** point is especially useful for volunteers whose availability fluctuates. **FAIR** - `#action/h1` **Directly relevant.** Dormant privileged accounts are an ungoverned dependency surface, and **a distributed ecosystem multiplies the exposure** — every mirror, index, and package source with its own maintainer list. **The "who can still push to this" question is a governance question FAIR should be asking.** **Personal / vault** - `#action/h1` **AUDIT HER OWN PRIVILEGED-ROLE LISTS.** Post Kinds, Outpost, Social Webmention Importer, RSS Chat Routing, the deploy repos, and the `courtneyr-dev/claude-config` repo — **who still has commit or admin access who hasn't used it?** This is a one-hour job and it is exactly the deferred task the article is about. - `#action/h1` **The reframe is the keeper:** account control, not merit. **It changes the threshold and makes generosity free.** - `#action/h2` **Eighth enforcement-boundaries instance**, and the cleanest statement of the calendar-trigger version. **A scheduled check binds; an intention doesn't.** - `#action/h2` **Reversibility reduces resistance** — a genuinely portable insight for any role, status, or access decision. - `#action/h3` **Verify the author** on the live page before citing by name. - `#action/h3` **Find Mattia Verga's Fedora script** — the only concrete implementation named. ## 🧪 Hypotheses 1. **The dormant-account hypothesis.** Inactive privileged accounts are disproportionately attractive targets because compromise goes unnoticed. **The argument's strongest leg and entirely uncited.** *Mechanism is sound; no evidence offered.* 2. **The reframe hypothesis.** Asking about account control rather than merit lowers the threshold, reduces social cost, and improves security outcomes simultaneously. **The piece's central and best idea.** *Reasoned, unmeasured.* 3. **The reversibility hypothesis.** Easy reinstatement reduces resistance to removal, because the loss becomes survivable. *Psychologically plausible, asserted.* 4. **The identity hypothesis.** People resist losing privileges because the role has become part of their self-concept. *An honest diagnosis; standard in community management, uncited.* 5. **The good-enough hypothesis.** A crude annual manual review outperforms an automated system that never gets built. *Almost certainly right, and the most practically useful claim.* 6. **The scheduled-trigger hypothesis.** A recurring calendar moment converts agreement into action where intention does not. **Eighth instance of this pattern in the batch.** *Consistent across sources, unmeasured anywhere.* 7. **The mutual-benefit hypothesis (reviewer).** Removal also relieves the departing maintainer of an unbounded liability they're no longer discharging. *Not made by the author; would strengthen the feelings argument.* ## 📊 Methodology **Design: a short practitioner how-to.** **No data, no study, no incident analysis, one named implementation.** It is advice from experience, and it does not present itself otherwise. | Claim | Basis | Strength | |---|---|---| | Projects grant more than they revoke | **Asserted from experience** | **Uncontroversial**; anyone who has run a project recognises it. | | Dormant accounts are a common attack vector | **Asserted** | **Mechanism is sound; zero citations.** The load-bearing claim and the weakest sourcing. | | Three obstacles: boring, complicated, feelings | **Practitioner observation** | **Credible and well-chosen.** Recognisable, unmeasured. | | Generous thresholds are adequate | **Follows from the reframe** | **Strong as reasoning** — it derives from what the policy is actually for. | | Reversibility reduces resistance | **Asserted** | **Plausible**, no evidence. | | Fedora requires checking half a dozen services | **Insider knowledge** | **Specific and checkable**; the strongest concrete detail. | | The policy features work | **Recommendation, not finding** | **Judge on utility.** No adoption outcomes reported. | **Strengths.** - **It concedes the objections rather than arguing them away.** *"They only seem like no fun because they are"* is a better opening than any motivational framing. - **It refuses perfectionism explicitly and repeatedly** — *"you don't need to wait for that"*, *"better than nothing"*, *"the goal isn't to be rigorous and precise."* - **It identifies which obstacle can't be half-done** — the feelings one — and treats it differently. **That's a real distinction, not a hedge.** - **It credits a named individual for the implementation.** - **It ends by admitting the policy will need iterating:** *"It will take a few tries to get the policy just right."* - **The eight features are specific enough to adopt**, with suggested numbers (six or twelve months) and an enumerated activity list. **What is not established.** - **The security claim carries no evidence.** No incident, no study, no supply-chain report — and this is what would persuade a reluctant project. - **No adoption outcomes.** Nothing about what happened at Fedora or anywhere else after implementing this: how many were removed, how many objected, whether anyone returned. - **No failure cases.** No project where the policy caused harm, drove people away, or was abandoned. - **No counter-argument considered** — notably that a large maintainer list can itself be a resilience property (bus factor), or that removal signals decline to outside observers. - **"Common attack vector" is unquantified.** Common relative to what? **Bias checks.** *Vendor interest* — **none**; no product, no service being sold in the captured text. *Survivorship* — mild: the recommended approach is described, not alternatives that failed. *Self-reported* — entirely, and openly. *False precision* — **absent, deliberately**; *"six or twelve months is probably a good place to start"* is appropriately loose. *Anecdote generalised* — one project (Fedora) grounds general advice, and Fedora is explicitly flagged as *"large and complicated"*, which is honest about its atypicality. *Newer-is-better* — n/a. **The dominant limitation is simply that it's short**: 798 words of advice with one worked example and no evidence for its central risk claim. ## ❓ Questions 1. **What is the evidence for dormant-account compromise?** **The most important gap.** The mechanism is obvious; the frequency is asserted. 2. **What happened at Fedora after implementing this?** Removal counts, objection rates, reinstatements — all available in principle, none reported. 3. **Does a shrinking maintainer list harm bus factor or external perception?** **The obvious counter-argument, unaddressed.** 4. **Where is Mattia Verga's script?** Named, unlinked, and the only concrete implementation. 5. **How does this interact with projects where maintainership confers voting or governance rights?** Emeritus keeping *"voting privileges on certain issues"* is mentioned in passing and has real governance implications. 6. **What about maintainers who are active but unresponsive?** The policy addresses dormancy, not the harder case of someone present and blocking. 7. **Does notice-before-removal create a perverse incentive** — a single token commit to reset the clock? **The generous framing arguably invites this**, and it may be fine given the security purpose, but it isn't discussed. ## 🔮 Future Research - **Find supply-chain incident data** on dormant or transferred maintainer accounts. **This is the citation the piece needs**, and it exists. - **Locate Mattia Verga's script** and Fedora's inactive-packager policy — a running implementation at real scale. - **Ask about outcomes** — what a project actually experienced after adopting this. - **Look for the counter-case:** a project that trimmed and regretted it, or where removal damaged succession. - **Check WordPress's current practice** for wp.org commit access, plugin committers, and GitHub org membership. **Does any equivalent policy exist?** - **Read the piece against WP Rocket's triage-ownership finding** — the same root problem from opposite ends. ## 💡 Implications **Practice.** One action and one reframe. **The action:** put a recurring calendar entry after each release and ask *"have I seen So-and-so around lately?"* — crude, annual, and better than the automated system you haven't built. **The reframe:** you are asking whether someone still controls their account, not whether they've earned their status. **That makes generosity free.** **Policy.** The eight features are adoptable nearly verbatim, and the design principle underneath them is worth extracting: **make the loss reversible and the removal ceremonial.** Easy reinstatement plus emeritus status plus public acknowledgment plus *"if someone wants to remain, let them"* means being removed costs almost nothing — **which is exactly why it becomes possible.** **Security.** **This is a supply-chain argument wearing community-management clothes.** A dormant privileged account is an unwatched credential with commit rights to code other people run. **The project's inactive-maintainer list is an inventory of its softest targets**, and it is usually public. For WordPress specifically, plugin and theme committer lists on widely-installed extensions are the highest-value version of this exposure. **Education.** *"'Fun' and 'important for the project' aren't the same"* is a good line for teaching maintenance work generally, and the furnace-filter analogy makes it concrete without moralising. **For Courtney's practice.** Three things. **The audit is a real one-hour task** across her own plugin repos, deploy repos, and the config repo. **The reframe is the durable idea** — control, not merit — and it changes the threshold. And **this is the eighth enforcement-boundaries instance in the batch**, with the cleanest statement of the calendar-trigger form: **a scheduled check binds where an intention doesn't.** ## 🧠 Learning Styles Assessment - **Visual** — Absent. No images or diagrams in the capture. **Appropriate for the length**; nothing here needs one. - **Aural** — Not applicable to this source. - **Verbal** — **Strong.** Plain, direct, economical. The furnace-filter analogy is the only ornament and it earns its place. - **Kinesthetic** — **Strongest dimension.** Eight specific, adoptable features with suggested thresholds, an enumerated activity list, a named implementation, and explicit permission to start crudely. - **Logical** — **Strong for the length.** Problem → why it doesn't happen → address each obstacle → policy features. **The structure is the argument**, and the third obstacle is deliberately handled differently from the first two. - **Social** — **Good.** The entire second half is about how removal feels to the person removed, and one contributor is credited by name. - **Solitary** — **Strong.** Fully self-contained, actionable on a first read. - **Naturalistic** — Not applicable, beyond the furnace analogy. **Reading level estimate.** Roughly grade 10–11. **The most accessible source in this batch.** Vocabulary is plain, sentences short, and the only assumed context is having a project with a maintainer list — no jargon beyond *commits*, *pull requests*, and *mailing list posts*, all standard. ## 📊 Accessibility Assessment Assessed from the captured text, as a **web article**: 1. **Perceivable — non-text content (1.1.1).** No images in the capture. **Pass by absence.** 2. **Perceivable — info and relationships (1.3.1).** **Strong.** Clear heading structure (*"Overcoming the objections"*, *"Creating an inactive maintainers policy"*), and the eight policy features extracted cleanly as discrete blocks with bolded leads. **Everything survived extraction**, which is notably better than several sources in this batch. 3. **Perceivable — contrast (1.4.3, 1.4.11).** Not assessable from the scrape. **Not assessed.** 4. **Operable — link purpose (2.4.4).** **Weak in effect.** Mattia Verga and the script are named; **no link surfaced in the capture.** For the article's only concrete implementation, a link would be the single most useful addition. 5. **Operable — timing, seizures (2.2, 2.3.1).** No timed or moving content. **Pass.** 6. **Understandable — language and readability (3.1).** **Excellent, and the best in this batch.** Short paragraphs, plain vocabulary, one homely analogy, no undefined jargon. **A newcomer to open-source governance can read this and act on it.** 7. **Robust — parsing (4.1).** **Pass.** Clean extraction, structure intact. **Notable good practice:** **the policy features are structured as a list with bolded opening statements**, so a reader skimming by heading or emphasis gets the whole policy without reading the prose. **That is genuine design for scanning**, and it means the actionable content is reachable at low cost. **Highest-value remediation:** link the Fedora script. ## 🌍 DEIB Assessment - **The whole second half is inclusion design, and it's unusually well done.** The problem is that removal humiliates people, and every remedy offered is structural rather than tonal: **notice before removal**, **explicit consent to remain** (*"If someone wants to remain, let them"*), **public acknowledgment**, **emeritus status with retained privileges**, and **easy reinstatement**. **Nowhere does it advise being tactful.** It removes the sting from the architecture instead — which works regardless of who is delivering the message or how good they are at it. - **Easy reinstatement has a real and unstated equity dimension.** People step back from volunteer roles for **caregiving, illness, disability flares, job loss, immigration disruption, and burnout** — and those causes are not evenly distributed. **A policy requiring re-application after a lapse penalises exactly the people whose availability is least under their own control.** *"Don't make them go through the whole process again"* is therefore an accessibility provision, whether or not the author framed it that way. **It is the most quietly important line in the piece.** - **The generous threshold compounds that.** Asking *are you still in control of your account?* rather than *have you contributed enough?* means someone managing a chronic condition, a new baby, or a demanding period of paid work does not lose status for a quiet year. - **Emeritus as memory retention.** Keeping people listed, reachable, and enfranchised on some issues preserves **institutional knowledge that would otherwise leave with them** — which is a direct mechanism for the transmission failure Cunningham describes elsewhere in this batch. **Alumni who remain contactable are a knowledge channel.** - **The identity framing is compassionate and accurate.** *"People who earn privileges absorb that role into their identity"* treats attachment as a normal human response rather than as ego, which is both truer and more useful. - **An unexamined risk worth naming.** *"Have I seen So-and-so around lately?"* — the crude manual heuristic — **relies on the reviewer's perception, which is not neutral.** People who work in less visible parts of a project, who don't participate in synchronous channels, who are in other time zones, or who are simply less socially prominent are **less likely to be "seen around"** regardless of their actual contribution. **The article's own advice to define activity broadly and check multiple services mitigates this** — but the fallback heuristic it offers does not, and the gap goes unmentioned. - **Inclusive language.** Neutral throughout. One contributor named and credited. ## ✅ Logical Validity **Sound reasoning.** 1. **The reframe is the strongest move and it is properly derived.** Asking what the policy is *for* — account control, not merit — **changes what threshold is correct.** The conclusion follows from the purpose rather than from preference. 2. **Obstacles are conceded, not argued away.** *"They only seem like no fun because they are."* **Granting the objection makes the response credible.** 3. **The three obstacles are treated differently, and correctly.** Two can be half-done; the third can't. **That distinction is doing real analytical work.** 4. **Perfectionism is refused explicitly** — *"you don't need to wait for that"* — which pre-empts the most common way this task gets deferred. 5. **The feelings remedy is structural rather than tonal**, so it doesn't depend on the messenger's skill. 6. **The policy admits it will need iteration:** *"It will take a few tries to get the policy just right."* 7. **The furnace analogy is apt** — an unglamorous recurring maintenance task with a safety consequence, which is precisely the category. **Fallacies and weaknesses.** 1. **The load-bearing security claim is uncited** — `#fallacy/appeal-to-unstated-evidence`. *"Compromised accounts remain a common attack vector"* is the argument's foundation and carries no incident, study, or figure. **Sound mechanism, absent evidence.** 2. **No counter-argument considered** — `#fallacy/one-sided-argument`. **Bus factor is the obvious one**: a larger maintainer list is a resilience property, and trimming it reduces the pool of people who could step back in. Never mentioned. 3. **No outcome data** — Fedora runs this and nothing is reported about what happened. 4. **No failure case** — no project where this backfired. 5. **"Common" is unquantified** — common relative to what baseline? 6. **A perverse incentive goes unexamined** — notice-before-removal plus a generous threshold means a single token commit resets the clock. **Probably acceptable given the security purpose, but the article doesn't notice the question.** 7. **The visibility heuristic is not neutral** — *"have I seen So-and-so around lately?"* imports the reviewer's perceptual biases, and the article recommends it without caveat. **Tone of voice.** Plain, unpretentious, and notably free of moralising for a piece about security hygiene. **The defining quality is that it grants every objection before answering it** — the work is boring, the definition is genuinely fuzzy, the feelings are real — which makes the advice land as practical rather than scolding. The register is a program manager who has done this and knows why you haven't. **The furnace filter is the only rhetorical flourish**, and it's chosen well: domestic, unglamorous, and about safety rather than virtue. **The one place it under-reaches** is the security claim, where the tone stays conversational at exactly the point where a citation would do more work than a sentence. ## 🛡️ DARVO Analysis **Not applicable to this source.** DARVO describes a pattern in an accused party's account of alleged wrongdoing — denial, attacking the accuser, reversing victim and offender. **This is a governance how-to about maintainer lists.** No accusation, no accused party, no contested harm. **One adjacent observation, and it's the reason the piece works.** There is an obvious blame framing available and it is comprehensively declined. **Inactive maintainers could easily be characterised as freeloaders holding privileges they no longer earn** — the "earning enough points" framing the author explicitly rejects. Instead: - Their attachment is described as **identity**, not entitlement: *"People who earn privileges absorb that role into their identity."* - The failure to remove them is attributed to **the project's** avoidance, not their conduct. - The remedy is built around **honouring them** — emeritus status, public praise, retained privileges, easy return. - And the policy contains **no override**: *"If someone wants to remain, let them."* **A piece about revoking access that treats the people losing access as valued contributors throughout** is a deliberate construction. **Ninth source in this batch to decline an available blame framing**, and one of the clearest. ## 🎯 Conclusion **Bottom line.** 798 words, no evidence, and one of the most immediately actionable things in this batch — because it fixes the framing rather than the procedure. **The reframe:** > *"the bigger concern is 'is this person still in control of their account?' not 'is this person earning enough points to keep their privileges?'"* **Change the question and the threshold changes with it.** Merit framing makes removal a judgment on someone you like, which is why the task never gets done. **Control framing makes it a routine check, and makes generosity free** — one commit in twelve months fully answers the question. The policy becomes kinder and more effective at once, which is unusual enough to be worth noticing. **The security case is correct and unevidenced.** *"Compromised accounts remain a common attack vector, and it's much easier to escape notice if the account owner isn't using the account."* **The mechanism deserves stating more sharply than he does: dormancy is not incidental to the risk, it is the attractive property.** Compromising an active maintainer means racing their attention; compromising a dormant one means nobody is watching. **A project's inactive-maintainer list is a public inventory of its softest targets.** And the piece cites nothing — no incident, no study, no supply-chain report — which is the one gap that matters, because it's what would move a reluctant project from *we should* to *we must*. **The feelings remedy is the best-designed part**, and it is structural rather than interpersonal. He never advises tact. He advises **removing the stakes**: notice first, emeritus status, public acknowledgment, retained privileges, *"if someone wants to remain, let them"*, and above all — > *"It's much easier to let a role go if you know you can easily get it back later."* **Reversibility is what makes the loss survivable.** And it has an equity dimension he doesn't name: people step back for caregiving, illness, disability, job loss, and burnout, and those causes aren't evenly distributed. **A policy that makes you re-apply penalises exactly the people whose availability is least under their own control.** *"Don't make them go through the whole process again"* is an accessibility provision. **The most practically useful line** is the anti-perfectionism one: *"Again, it would be nice if you could automate it. **You don't need to wait for that.**"* Because *"we'll do it properly once we've built the tooling"* is precisely how this gets deferred indefinitely — **and the deferral is the vulnerability.** **What's missing.** No citation for the central risk claim. No outcome data, though Fedora runs this. No failure case. And **no engagement with the obvious counter-argument** — that a larger maintainer list is itself a resilience property, and trimming reduces the pool who could step back in. Also unexamined: the fallback heuristic, *"have I seen So-and-so around lately?"*, **imports the reviewer's perceptual biases** against people who work in less visible parts of a project or in other time zones. **And one thing he should have said.** He treats the security harm and the feelings harm as competing considerations. **They point the same way.** A maintainer who drifted away and still holds commit rights is carrying an unbounded liability on the project's behalf, indefinitely, for a role they aren't performing. **Removing them is also a favour to them** — and that framing would do more work than any amount of emeritus ceremony. **For this batch, it's the eighth enforcement-boundaries instance and one of the cleanest.** *"Check for inactive maintainers at a set time."* Everyone already agrees the list should be tidy; that agreement has produced nothing. **A calendar trigger binds where an intention doesn't** — the same structure as WP Rocket's *"someone now owns GitHub triage,"* Monzo's *"commitment has shape,"* and Meta building the constraint into the interview task rather than into a rule. **Next steps.** 1. **Audit her own privileged-role lists** — plugin repos, deploy repos, config repo. **A one-hour job.** 2. **Find the supply-chain evidence** the piece needed and didn't cite. 3. **Raise this with WordPress Meta and Plugins** — directory committer lists are the highest-value version of this exposure in the ecosystem. ## 🧱 Refactor Appendix ### Literature Split Pad (H3) > [!quote] `#atom/literature/h1` > "For the most part, the bigger concern is 'is this person still in control of their account?' not 'is this person earning enough points to keep their privileges?' So if someone's activity isn't what you'd want for them to initially earn maintainer status, that's probably okay." **The reframe, and the whole piece.** Changing what the policy is *for* changes the correct threshold — and makes generosity free rather than costly. > [!quote] `#atom/literature/h1` > "Compromised accounts remain a common attack vector, and it's much easier to escape notice if the account owner isn't using the account." **Dormancy is the attractive property, not an incidental one.** Correct mechanism, zero citations — the piece's one real gap. > [!quote] `#atom/literature/h1` > "It's much easier to let a role go if you know you can easily get it back later." **Reversibility as the mechanism for reducing resistance.** Generalises to any role, status, or access grant. **And it's an equity provision**, since availability lapses are unevenly distributed. > [!quote] `#atom/literature/h1` > "Again, it would be nice if you could automate it. You don't need to wait for that." **The anti-paralysis line.** "We'll do it properly once we've built the tooling" is how the task gets deferred forever, **and the deferral is the vulnerability.** > [!quote] `#atom/literature/h2` > "Project and community management tasks often end up on the 'avoid: no fun' pile. They only seem like no fun because they are. But 'fun' and 'important for the project' aren't the same." **Concedes the objection instead of arguing it away**, which is why the advice lands as practical rather than scolding. > [!quote] `#atom/literature/h2` > "People who earn privileges absorb that role into their identity and they don't want to let it go." The honest diagnosis of why offboarding is hard. **Identity, not entitlement** — truer and more useful. > [!quote] `#atom/literature/h2` > "Check for inactive maintainers at a set time. If you have calendar-based releases, check at a given point in the release cycle. Right after the release is a good starting point." **Eighth enforcement-boundaries instance.** A scheduled trigger binds; an intention doesn't. > [!quote] `#atom/literature/h3` > "Give people a chance to respond... If someone wants to remain, let them." **No override in the policy.** The removal is real and the consent is real, which is what makes it survivable. > [!quote] `#atom/literature/h3` > "This is a case where the perfect quickly becomes the enemy of the good (or okay-ish)." The governing principle, with the parenthetical doing the work. > [!quote] `#atom/literature/h3` > "Changing the air filter in my furnace isn't fun, but it's important for the health and safety of my family." The one flourish, well chosen: domestic, unglamorous, and about safety rather than virtue. ### Atomic Split Pad (H4) - `#atom/zettel/z1` **Ask what the policy is for, and the right threshold follows** — Removing inactive privileges is a question about account control, not merit. Framing it as merit makes it a judgment on people you like, which is why it never happens; framing it as control makes generosity free. - `#atom/zettel/z1` **Dormancy is what makes an account attractive to compromise** — An active account's owner is an unpaid monitor: unexpected activity gets noticed. A dormant privileged account has commit rights and no one watching, which makes an inactive-maintainer list an inventory of soft targets. - `#atom/zettel/z1` **Reversibility makes loss survivable** — People resist giving up a role because it feels permanent. Guaranteeing easy return removes most of the resistance, and it costs nothing. - `#atom/zettel/z1` **Make the kindness architectural, not interpersonal** — A process designed so removal is announced, honoured, consented to, and reversible works regardless of who delivers the message. Relying on tact makes the outcome depend on the messenger. - `#atom/zettel/z1` **A scheduled trigger binds; an intention does not** — Universal agreement that something should be done produces nothing. What converts agreement into action is a specific recurring moment tied to something that already happens. - `#atom/zettel/z1` **Concede the objection before answering it** — Granting that the work is genuinely boring, or the definition genuinely fuzzy, makes the advice credible. Arguing that a tedious task is secretly enjoyable does not. - `#atom/zettel/z1` **Automation is a destination, never a prerequisite** — Waiting to do something properly is how it goes undone. A crude version that ships beats a rigorous one that doesn't, especially when the delay is itself the risk. - `#atom/zettel/z1` **Visibility heuristics import the reviewer's biases** — "Have I seen them around lately?" systematically undercounts people working in less visible areas, in other time zones, or in asynchronous channels. Broad, multi-source activity definitions mitigate what perception does not. ### Fleeting Queue - `#atom/fleeting/f1` **AUDIT HER OWN PRIVILEGED-ROLE LISTS** — Post Kinds, Outpost, Social Webmention Importer, RSS Chat Routing, deploy repos, `courtneyr-dev/claude-config`. **Who still has commit or admin access and hasn't used it? One hour.** - `#atom/fleeting/f1` **The reframe is the keeper:** account control, not merit. **Changes the threshold, makes generosity free.** - `#atom/fleeting/f1` **EIGHTH enforcement-boundaries instance**, and the cleanest calendar-trigger form. - `#atom/fleeting/f1` **Raise with WP Meta and Plugins** — directory committer lists on widely-installed plugins are the ecosystem's highest-value dormancy exposure. **Supply chain, not tidiness.** - `#atom/fleeting/f1` **Find the supply-chain incident evidence** the article needed. It exists; the piece cites none. - `#atom/fleeting/f1` **Easy reinstatement is an accessibility provision** — availability lapses (caregiving, illness, disability, burnout) are unevenly distributed. **The author doesn't frame it that way and should.** - `#atom/fleeting/f1` **Maintainer emeritus as institutional-memory retention** — a mechanism for Cunningham's transmission problem. - `#atom/fleeting/f1` **The unaddressed counter-argument: bus factor.** A larger list is a resilience property; trimming reduces who could step back in. - `#atom/fleeting/f1` **The mutual-benefit framing he misses** — removal relieves the departing maintainer of an unbounded liability. Would ease the conversation more than emeritus ceremony. - `#atom/fleeting/f1` **Verify the author** (strong indications of Ben Cotton) and **find Mattia Verga's Fedora script**. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Removing Inactive Maintainers.md|Removing Inactive Maintainers by Duck Alignment Academy - byline not in capture (likely Ben Cotton)]] ## Highlights - In open source projects, we tend to grant privileges far more often than we remove them. This is understandable, but risky. First, keeping inactive people on the maintainer list means someone may go to them with a question and be frustrated when they don’t get an answer. More importantly, it presents a security risk. Compromised accounts remain a common attack vector, and it’s much easier to escape notice if the account owner isn’t using the account. It behooves the project to keep the maintainer (or other privileged role) list tidy. ([View Highlight](https://read.readwise.io/read/01m0zg6kd14as3tp648cv7974w)) - Note: DORMANCY IS THE ATTRACTIVE PROPERTY, not an incidental one — worth stating more sharply than he does. Compromising an ACTIVE maintainer means racing their own attention: unexpected commits get noticed, unexpected 2FA prompts get questioned. Compromise a dormant account and there is nobody to notice. A PROJECT'S INACTIVE-MAINTAINER LIST IS A PUBLIC INVENTORY OF ITS SOFTEST TARGETS. GAP: this is the argument's load-bearing claim and it carries NO citation — no incident, no study, no supply-chain report, despite abundant documented cases. That's the one thing that would move a reluctant project from "we should" to "we must." ACTION: WordPress plugin/theme committer lists on widely-installed extensions are the ecosystem's highest-value version of this. #atom/zettel/z1 - **Define “inactive” generously.** For the most part, the bigger concern is “is this person still in control of their account?” not “is this person earning enough points to keep their privileges?” So if someone’s activity isn’t what you’d want for them to initially earn maintainer status, that’s probably okay. ([View Highlight](https://read.readwise.io/read/01m0zg6854m46wcz00ndtvmft0)) - Note: THE REFRAME, AND THE WHOLE PIECE. Merit framing makes removal a judgment on people you like — which is exactly why the task never gets done. Control framing makes it a routine check, and CHANGES THE CORRECT THRESHOLD: one commit in twelve months fully answers "do you still hold this account?" Generosity costs nothing against the security question and everything against the merit question, so the policy gets kinder AND more effective at once. That's rare. General principle: ask what the policy is FOR, and the right threshold follows. #atom/zettel/z1 - **Allow easy reinstatement.** If someone lapses and later wants to return, let them. Don’t make them go through the whole process again. It’s much easier to let a role go if you know you can easily get it back later. ([View Highlight](https://read.readwise.io/read/01m0zg6yjya7mm5x0rzr1n55gv)) - Note: REVERSIBILITY MAKES LOSS SURVIVABLE — and note the remedy for the feelings problem is ARCHITECTURAL, not interpersonal. He never advises being tactful; he removes the stakes. Combined with notice-first, emeritus status, public acknowledgment, and "if someone wants to remain, let them," the policy is designed so removal costs almost nothing — which is precisely why people accept it. Works regardless of who delivers the message. AN EQUITY POINT HE DOESN'T MAKE: people step back for caregiving, illness, disability flares, job loss, and burnout, and those causes are NOT evenly distributed. Requiring re-application penalises exactly the people whose availability is least under their own control. This is an accessibility provision. #atom/zettel/z1