One frustrating trend I’ve noticed in many open-source projects is maintainers closing issues as quickly as possible—often in a dismissive and even confrontational manner. It sometimes feels like a game, where the goal is to shut down as many issues as possible rather than foster meaningful discussion.

But here’s the thing: issues aren’t just demands for the maintainer to do work. They serve a much bigger purpose in open-source projects:

✅ They help users realize they’re not alone—people with the same issue can come together, share insights, or even hire someone to solve it.

✅ They serve as documentation—a record of what’s been discussed, what problems exist, and what solutions have been proposed.

✅ They create opportunities for new contributors—someone trying their hand at coding might pick up an issue, or someone with the same problem might decide to implement a fix.

✅ They signal what users actually need—even if the maintainer doesn’t plan to fix something, an open issue can indicate demand to potential contributors.

But when an issue gets shut down immediately, all of this breaks down. Closed issues don’t appear in GitHub’s default search, meaning 99% of people who might have seen it now won’t. This leads to:

• Duplicate issues because users can’t find past discussions.
• Missed opportunities for new contributors to pick up low-hanging fruit.
• Users feeling unheard, which can make them disengage from the project entirely.
• Preventing others from seeing the issue and potentially contributing.

So why do some maintainers do this? Why Maintainers Close Issues So Aggressively

There are a few common reasons:

🔹 Burnout & Overload – Many maintainers are drowning in issues, and closing them fast is a survival mechanism.

🔹 Entitlement Fatigue – Dealing with demanding users can make maintainers defensive and dismissive, even toward good-faith issues.

🔹 “Keeping the Board Clean” Mentality – Some maintainers see issues as a to-do list, not a place for discussion. They close anything that doesn’t fit their personal roadmap.

🔹 Power Trip – Let’s be honest—some people just like saying “no.” They get used to shutting things down and enjoy exerting control.

🔹 Lack of Interest – Not every maintainer wants new features or community discussions. Some prefer to build things their own way and reject anything that doesn’t align.

Of course, every project is different, and maintainers have the right to decide how they manage their issue tracker. But closing everything by default discourages contribution and community involvement. A Better Approach?

Instead of aggressively shutting things down, maintainers could:

✅ Leave issues open for discussion, even if they don’t plan to act on them.

✅ Use labels like “help wanted” or “waiting for contributors” instead of closing things outright.

✅ Let issues sit for a while to gauge community interest. If nobody cares, they’ll fade naturally. If people keep commenting, that’s a sign it’s worth keeping open.

✅ Recognize that open-source isn’t just about code—it’s about community. The issue tracker isn’t just for them, it’s for everyone who might contribute.

What’s your experience with this? Have you seen issue-closing behavior that helped or hurt a project?