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. > ## 🧭 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 A wooden fence at the edge of a horse pasture shrouded in fog. 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. There are a few reasons that trimming the maintainer list doesn’t happen. First, it’s boring, tedious work. Who wants to do that? Second, it’s complicated work. What does it mean to be “inactive”? Third, it can lead to [hurt feelings](https://duckalignment.academy/be-prepared-big-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). Let’s look at each of the reasons in turn. #### Overcoming the objections 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. Changing the air filter in my furnace isn’t fun, but it’s important for the health and safety of my family. 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. “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. You can start by just asking yourself “have I seen So-and-so around lately?” If the answer is “yes”, then they’re active. Again, it would be nice if you could automate it. You don’t need to wait for that. The feelings objection is the hardest one. We’re all friends here and we don’t want to hurt our friends’ feelings. Unlike the other two, you can’t really half-ass this one, so you need a policy that treats people with kindness. Let’s move on to that. #### Creating an inactive maintainers policy Here are some features of a good inactive maintainers policy: * **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 is probably a good place to start. 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. * **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. * **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. * **Automate what you can.** The time spent really does pay off pretty quickly. Fedora is a large and complicated project, so evaluating activity requires checking half a dozen services. Mattia Verga wrote a [script](https://forge.fedoraproject.org/packaging/find-inactive-packagers) that handles the checks and creates issues in a repo to track the inactive packagers. * **Don’t remove anyone without notice.** This is a big part of the “don’t hurt your friends’ feelings” requirement. Give people a chance to respond. 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. If someone wants to remain, let them. * **Conspicuously acknowledge the people you’re removing.** Add people as a “maintainer emeritus”. Mention them in a blog post, release notes, or other vehicle for public praise. * **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. * **Leave some privileges for people on emeritus status.** 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. It will take a few tries to get the policy just right. Don’t be afraid to try it., Removing Inactive Maintainers, Duck Alignment Academy - byline not in capture (likely Ben Cotton), 01m0zfwg3phtvge4n84ve1vw6b.